Re: Troubleshooting slow DNS lookup
> > Standards Track. > > RFC 2671 Extension Mechanisms for DNS (EDNS0) > > RFC 3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements > > Unfortunately RFC is not considered as good enough ... unless if we > can find an actual proof that can be replicated :( disable dnssec then. If the RFC above is not good enough, DNSSEC isn't as well. Maybe you will be able to disable some other standards newer than 10 years (2671 is from August 1999) that will make them change their minds. > > dig +dnssec dnskey . On 08.12.10 17:51, Rianto Wahyudi wrote: > This for some reason works without any problem : Check carefully again, if the answer did not start with: ;; Truncated, retrying in TCP mode. > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> +dnssec dnskey . > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64905 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 14 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;. IN DNSKEY [...] -- 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. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Silently drop queries for AAAA records
On 12/08/2010 07:40 AM, Niobos wrote: On 2010-12-07 23:31, David A. Evans wrote: I'm in the mood to prove a point. I have a very poorly written application that is generating a few hundred queries per second of completely bogus records before attempting a lookup of the correct A records. This is because the application was compiled with a IPv6 interface enabled on the severs so it assumes that v6 is available. It is not. The application owner does not see an issue as they get the handful NXDOMAIN responses back in ~2 ms for each valid response and don't see any performance hit. Actually, this is the desired behavior for IPv6 applications. They prefer v6, so they first try to connect over v6 (hence the request). When they either (1) don't get an IPv6 address or (2) they see that they have no route to that IPv6 address or (3) the v6 connection times out; they fall back to IPv4. Not quite. The desired behaviour for *all* applications these days is to call the system library getaddrinfo() call, and loop over the responses. getaddrinfo() in turn decides what DNS lookups to perform, and on most platforms will omit lookups if it doesn't have a routable IPv6 address. Whether or A responses are preferred depends on the application of RFC 3484 sorting rules keyed of available local addresses as well as the remote. Native v6 -> Native v6 is preferred, then Native v4 -> Native v4, then tunneled v6 -> tunneled v6, and so forth. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Troubleshooting slow DNS lookup
In message , Rian to Wahyudi writes: > Hi Mark, > > Thanks for your quick response ! > > > Standards Track. > > RFC 2671 Extension Mechanisms for DNS (EDNS0) > > RFC 3226 DNSSEC and IPv6 A6 aware server/resolver message size requiremen= > ts > > Unfortunately RFC is not considered as good enough ... unless if we > can find an actual proof that can be replicated :( > > I also done some dnssec trace demonstration, and it still not a good > enough reason : > ie : dig www.anyhostname.com +trace +dnssec . > This test always fail and it produce FWSM log entry similar to: > : %FWSM-2-106007: Deny inbound UDP from 198.142.0.51/53 to > 10.0.0.1/64788 due to DNS Response I also suggest that you ask your firewall people to talk to the CISCO TAC about how to properly configure the firewall for a nameserver that supports EDNS. The defaults are not setup for a nameserver that supports EDNS. If they don't want to do that read what CISCO recommends here: https://supportforums.cisco.com/message/3221565#3221565 > > Informational. > > RFC 4294 IPv6 Node Requirements > > > > http://labs.ripe.net/Members/anandb/content-testing-your-resolver-dns-rep= > ly-size-issues > > > > > > How about the root servers? > > > >> - Any example of dns record that send packet larger than 512 ? > > > > The root servers. > > > > =A0 =A0 =A0 =A0dig +dnssec dnskey . > > This for some reason works without any problem : Well if you ask the root servers dig +dnssec dnskey . @a.root-servers.net With just "dig +dnssec dnskey ." you are talking to your own server so are not going through the firewall. You will also notice it took 1/2 a second to get that answer so named did several different attempts in that 1/2 second. > ;; Query time: 547 msec -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
m master file managed-keys.bind failed
Who is supposed to own /var/named? I understand the reason for the following error: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found managed-keys.bind.jnl: create: permission denied managed-keys-zone ./IN: sync_keyzone:dns_journal_open -> unexpected error Except for the directories where bind needs to write while running, I thought the rest of the tree was owned by root. managed-keys.bind seems to be at the very top of the tree in /var/named. Since that is owned by root, I can understand why named running as bind won't write to it. That is obviously not right so who does own directories not owned by bind? This is on a test box so nothing terrible is happening right now, but we are preparing for dnssec so now is the time to get everything as it will be on the production system when the time comes. Is there, by chance, a "make it good" script where it just chown's everything to the proper directories? That would be very helpful. Martin McCormick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Troubleshooting slow DNS lookup
On Wed, 8 Dec 2010, Rianto Wahyudi wrote: > > - Does any one have a good example of prominent website that have > DNSEC setup properly other than paypal? > - Any example of dns record that send packet larger than 512 ? ; <<>> DiG 9.6.2-P2 <<>> +multiline +dnssec www.cam.ac.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27436 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 11 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.cam.ac.uk. IN A ;; ANSWER SECTION: www.cam.ac.uk. 77902 IN A 131.111.8.46 www.cam.ac.uk. 77902 IN RRSIG A 5 4 86400 20110103030147 ( 20101204030850 34770 cam.ac.uk. m80OuIdqTxhSGGCbpzoksKHjdSyfaS9eALUEE0X7dwnh Z2jrhoGKaz2snJ3XbRUwebJSNSt7Ej4Mw50buRD77Rlj kMumdYEmzYDSOewZ93CEE54nVzkGUQWYnVxsK1uRxSYK vA== ) ;; AUTHORITY SECTION: cam.ac.uk. 4362 IN NS dns0.eng.cam.ac.uk. cam.ac.uk. 4362 IN NS bitsy.mit.edu. cam.ac.uk. 4362 IN NS ns2.ic.ac.uk. cam.ac.uk. 4362 IN NS dns0.cl.cam.ac.uk. cam.ac.uk. 4362 IN NS authdns1.csx.cam.ac.uk. cam.ac.uk. 4362 IN NS authdns0.csx.cam.ac.uk. cam.ac.uk. 4362 IN NS dns1.cl.cam.ac.uk. cam.ac.uk. 81614 IN RRSIG NS 5 3 86400 20110105004959 ( 20101206071226 34770 cam.ac.uk. XuKl+Pwh7HenDLpOmoIssHE5ZOSug1b9+SLhIEdXtWDb cB4zViCtCxJFz8yC41feAy5g2w+6Cc9RAiNexZf3E+PU gQQd+w3UHn5VwNRJroDw4TKMAlsG7LcFvOYuPOKeXyIv Jw== ) ;; ADDITIONAL SECTION: ns2.ic.ac.uk. 73348 IN A 155.198.142.82 dns0.cl.cam.ac.uk. 14636 IN A 128.232.0.19 dns0.cl.cam.ac.uk. 14636 IN 2001:630:200:ac70::d:a0 dns0.eng.cam.ac.uk. 162 IN A 129.169.8.8 dns1.cl.cam.ac.uk. 14636 IN A 128.232.0.18 authdns1.csx.cam.ac.uk. 162 IN A 131.111.12.37 authdns1.csx.cam.ac.uk. 162 IN 2001:630:200:8120::d:a1 ns2.ic.ac.uk. 73348 IN RRSIG A 5 4 86400 20101228214539 ( 20101128205350 4743 ic.ac.uk. VGps8nLXC3hA9vuNKD9K4unAxNeL02U4DQuBe9XRXbgk OCRRQpgzxSNw8S+MS5H740EiquYCb4GhARRwP32Jpxya tR+eGlersDIsGZGpH88mZ9zm8kReZaHNTv3+ENU0fDKt LOou+4SfA+ca7/348PAKmRsR8EA/KpMFm6ofIYs= ) authdns1.csx.cam.ac.uk. 162 IN RRSIG A 5 5 86400 20110104233031 ( 20101206031205 34770 cam.ac.uk. JKDGs3+vXx+OkFGXQ+ZZZllikf4Q1ab9hiteQNthlQ6y j7nFtg6HvoGqPFT6DicPeMLUCI68GLpWKJcuC+Z8z5IE pMxnAKAjMKdlHibdRzTCT6JBu+4Q7w0opKo0cEI81i/G 8Q== ) authdns1.csx.cam.ac.uk. 162 IN RRSIG 5 5 86400 20101225154130 ( 20101125184850 34770 cam.ac.uk. CLGNGErElJOiOufuNl5M3q3rfZWlxxNzCIBHRf6hjuKS 1KfoAdhLuFJCTcYHj7seN0PqHeKi0cniKXIh1KPX9knk TUrzfxettAcige0vgez7t8HliB3001Xie49hujWYiZvP /g== ) ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Dec 8 17:17:18 2010 ;; MSG SIZE rcvd: 1088 Tony. -- f.anthony.n.finchhttp://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Views based on port number
Hi, For my home use, I'd like to use a DNSSEC-validating recursive resolver, preferably one I control myself. Since I don't want to install a server at home specifically for that, I'm trying to develop an alternative. My current idea is to host the RR on my public server, but I don't intend to serve the world, so I'd like to restrict this service to me, somehow. (I have a dynamic IP) So I was thinking of letting bind run additionally on a high random port, and configure my broadband router to do the matching NATting. That brings me to my actual question: How can I match clients based on the (destination/server) port they used to contact BIND? Is this possible? Or is there a much easier way to solve my problem and am I overly complicating things? And you never know: if anyone has ever installed BIND 9.7 on a dd-wrt box, that would solve my problem as well. Thanks, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: m master file managed-keys.bind failed
> Except for the directories where bind needs to write > while running, I thought the rest of the tree was owned by root. > managed-keys.bind seems to be at the very top of the tree in > /var/named. You can override the location of the file with the "managed-keys-directory" option (added in 9.7.1). > Is there, by chance, a "make it good" script where it > just chown's everything to the proper directories? That would be > very helpful. ...that's an interesting idea. Thanks. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: m master file managed-keys.bind failed
I wrote: > Who is supposed to own /var/named? I received a response from a kind soul from this list who reminded me of a directive new to bind9.7.1 that lets you determine where the managed-keys.bind file lives. I set up managed-keys-directory "/etc/namedb/working"; and all is now well with that zone. This appears to be a logical place for the file and there is nothing else in that directory which is already under bind ownership. I also asked: > Is there, by chance, a "make it good" script where it > just chown's everything to the proper directories? That would be > very helpful. It would be helpful, but as I did a find on /var/named and looked for everything owned by user bind, I realized that there really isn't all that much to do. The whole tree can be downed by root but anything that must be written by bind must be owned by bind and it will sure tell you if it tries to write to a directory owned by any other user such as root so sometimes, it is good just to look at the big picture and see that it is not difficult. Martin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Unusual TSIG problem
I just ran into an odd issue with a TSIG signed zone transfer. On occasion I was logging a clocks are unsynchronized message doing a transfer from a customer server at a site about 30 ms away. I dropped a note to the manager there asking that he look at the his system for a time issue. He checked and found no problems. Today I looked at the problem more closely. I realized that the problem was NOT a clock sync issue. They were probably within a millisecond of one another. I found the following in the log: Dec 8 06:26:18 ns1 named[67170]: zone XX.gov/IN: notify from 123.234.1.1#33372: refresh in progress, refresh check queued Dec 8 06:31:18 ns1 named[67170]: transfer of 'XX.gov/IN' from 123.234.1.1#53: failed while receiving responses: clocks are unsynchronized Dec 8 06:31:18 ns1 named[67170]: transfer of 'XX.gov/IN' from 123.234.1.1#53: Transfer completed: 1 messages, 397 records, 59674 bytes, 898.462 secs (66 bytes/sec) The transfer, probably due to a hardware problem was taking over 5 minutes to transfer the zone and RFC2845 suggests tha the difference between clocks should be limited to 300 seconds (5 minutes). This really means that, should the transfer take over 5 minutes, you get the unsynced clocks error. (4.5.2. TIME check and error handling) Clearly, something is broken when a zone transfer takes over 5 minutes. (This one SHOULD take about 2-3 seconds.) But the message certainly pointed in the wrong direction. Is there more appropriate language that might indicate that it could also be an effective time-out because the transfer took too long? Maybe "failed while receiving responses: clocks are unsynchronized or maximum transfer time exceeded"? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unusual TSIG problem
In message <20101208214221.566771c...@ptavv.es.net>, "Kevin Oberman" writes: > I just ran into an odd issue with a TSIG signed zone transfer. > > On occasion I was logging a clocks are unsynchronized message doing a > transfer from a customer server at a site about 30 ms away. I dropped a > note to the manager there asking that he look at the his system for a > time issue. He checked and found no problems. > > Today I looked at the problem more closely. I realized that the problem > was NOT a clock sync issue. They were probably within a millisecond of > one another. I found the following in the log: > Dec 8 06:26:18 ns1 named[67170]: zone XX.gov/IN: notify from 123.234.1.1 > #33372: refresh in progress, refresh check queued > Dec 8 06:31:18 ns1 named[67170]: transfer of 'XX.gov/IN' from 123.234.1. > 1#53: failed while receiving responses: clocks are unsynchronized > Dec 8 06:31:18 ns1 named[67170]: transfer of 'XX.gov/IN' from 123.234.1. > 1#53: Transfer completed: 1 messages, 397 records, 59674 bytes, 898.462 secs > (66 bytes/sec) > > The transfer, probably due to a hardware problem was taking over 5 > minutes to transfer the zone and RFC2845 suggests tha the difference > between clocks should be limited to 300 seconds (5 minutes). This really > means that, should the transfer take over 5 minutes, you get the > unsynced clocks error. (4.5.2. TIME check and error handling) 59674*8/397 = 1202 b/s that's slower than almost all dialup lines. If this happens regularly use transfer-format multiple-messages which results in smaller messages and more signatures. > Clearly, something is broken when a zone transfer takes over 5 > minutes. (This one SHOULD take about 2-3 seconds.) But the message > certainly pointed in the wrong direction. Is there more appropriate > language that might indicate that it could also be an effective time-out > because the transfer took too long? Maybe "failed while receiving > responses: clocks are unsynchronized or maximum transfer time exceeded"? > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: ober...@es.netPhone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > ___ > 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unusual TSIG problem
> From: Mark Andrews > Date: Thu, 09 Dec 2010 09:07:53 +1100 > > > In message <20101208214221.566771c...@ptavv.es.net>, "Kevin Oberman" writes: > > I just ran into an odd issue with a TSIG signed zone transfer. > > > > On occasion I was logging a clocks are unsynchronized message doing a > > transfer from a customer server at a site about 30 ms away. I dropped a > > note to the manager there asking that he look at the his system for a > > time issue. He checked and found no problems. > > > > Today I looked at the problem more closely. I realized that the problem > > was NOT a clock sync issue. They were probably within a millisecond of > > one another. I found the following in the log: > > Dec 8 06:26:18 ns1 named[67170]: zone XX.gov/IN: notify from > > 123.234.1.1 > > #33372: refresh in progress, refresh check queued > > Dec 8 06:31:18 ns1 named[67170]: transfer of 'XX.gov/IN' from > > 123.234.1. > > 1#53: failed while receiving responses: clocks are unsynchronized > > Dec 8 06:31:18 ns1 named[67170]: transfer of 'XX.gov/IN' from > > 123.234.1. > > 1#53: Transfer completed: 1 messages, 397 records, 59674 bytes, 898.462 > > secs > > (66 bytes/sec) > > > > The transfer, probably due to a hardware problem was taking over 5 > > minutes to transfer the zone and RFC2845 suggests tha the difference > > between clocks should be limited to 300 seconds (5 minutes). This really > > means that, should the transfer take over 5 minutes, you get the > > unsynced clocks error. (4.5.2. TIME check and error handling) > > 59674*8/397 = 1202 b/s that's slower than almost all dialup lines. > If this happens regularly use transfer-format multiple-messages which > results in smaller messages and more signatures. I agree that this should not happen. The hardware is obviously broken. It's just that the message resulted in a great deal of wasted effort looking at clock issues when the problem was completely unrelated to that. I'm just wondering if it is worthwhile to mention this possibility in the log message. The more detailed message would have caused me to note the time stamps on the messages immediately and realize what was going on. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with Bind-Kerberos-Windows-Linux
> I do this now the 3rd week. I was reading a lot of books and manuals, doing > a lot of configuration and sniffering etc. I looked in google for hours but > I could not find anyone that says - yes it works. It does work, but setting it up is very-very painful. Even if you do get it working, and document every step, a slightest mistake is at least an hour or two spent in troubleshooting. When configured properly it works, with a few limitations (in 9.7.2 at least). >Do you mean the policy in the active directory? No, I meant the update-policy option in BIND. It allows you to grant/deny ddns update permission to kerberos principals. >Btw. did you try to do it your own and succeeded? Yes, we succeeded and got GSS-TSIG in BIND working with Windows clients, Windows DHCP, and implemented our own GSS-TSIG client. Regards Sergiu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
