Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow
* Mark Andrews: > And the best way to deal with this is to have manufacturers update > https://www.kb.cert.org/vuls/id/457759 with their status. Yes it > should be a much bigger list than what is there. Every IoT vendor. > Every router vendor. Every OS vendor. Yes, ISC needs to put in a > offical status. If you have a internet connected product and the > manufacture is not on the list, contact the manufacture and ask > them to provide a status update. The real challenge are the vendors who do not realize they are embedding a copy of glibc in their product. I'm sure they exist. > The list may have a lot of "affected if run on a vulnerable OS" > responses. For most of these the solution will be "fix the OS, > relink if statically linked, and reboot the machine". Static linking is less of a concern, for once. The reason is that you need to jump through very special hoops to get a statically linked copy of nss_dns which uses a statically linked copy of libresolv. Regular distribution builds for static linking use static dlopen to dynamically link the required NSS libraries. Due to some implementation details, such statically linked binaries are not very portable between different glibc versions, and there's a clear warning at static link time that you need the DSOs for the same glibc version you are statically linking against at run time. ___ 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: CVE-2015-7547: getaddrinfo() stack-based buffer overflow
* Alan Clegg: > While I agree that the "major distributions" (and even the minor ones) are > getting patches out, I'd like to point out something that Alan Cox posted > over on G+: > > "You can upgrade all your servers but if that little cheapo plastic box on > your network somewhere has a vulnerable post 2008 glibc and ever does DNS > lookups chances are it's the equivalent of a trapdoor into your network." > > https://plus.google.com/+AlanClegg/posts/R1UkJjHMMB6 glibc is usually considered way too bloated for use in embedded devices. I'm sure there are some uses in this space, but glibc is probably not a relevant player in this field. That being said, there are apparently supported glibc ports to Android, specifically for running mostly unported GNU/Linux applications on top of Android devices (applications which do not work with Android's native Bionic libc, which is not affected by this issue). ___ 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: CVE-2015-7547: getaddrinfo() stack-based buffer overflow
* Ben Croswell: > Cyber folks asked if there was any way for the DNS servers to "protect" the > vulnerable clients. > The only thing i could see from the explanation was disabling or limiting > edns0 sizes. That is obviously not a long term option. EDNS0 buffer sizes do not apply to TCP responses, so this is not an effective mitigation, I'm afraid. ___ 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: Need to improve named performance
* Ed LaFrance: > Thanks for chiming in. Named is PID 8349 in my case. Here's a snippet > of the output from strace: > [pid 8351] send(3, "<30>Nov 11 13:07:25 named[8349]:"..., 107, > MSG_NOSIGNAL) = 107 <0.015232> > [pid 8353] send(3, "<30>Nov 11 13:07:25 named[8349]:"..., 103, > [pid 8353] <... send resumed> )= 103 <0.015034> This look like syslog logging is the culprit, each syslog message takes 15ms to complete. There could be several causes: syslogd is logging synchronously to disk (doing an fsync after each message), something else in the system is producing an extremely large number of messages (syslogd is single-threaded), or there is a request loop where writing out the syslog message for each reverse DNS request requires itself a reverse DNS lookup. You should also check if named is expected to log this many messages in the first place. You can pass "-s 200" to strace to see more of the logging message, so this should help to identify what's going on. I don't think this has got anything to do with the particular BIND version you use. ___ 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: Need to improve named performance
* Ed LaFrance: > Running BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5 on a quadcore xeon server > (3Ghz) with 2GB RAM. Named is being used only for rDNS queries against > our address space. You should really upgrade to the latest version on that branch (likely bind-9.3.6-20.P1.el5_8.5). > The bottom line is: I need to improve named performance. Tcpdump only > shows about 20 requests per second on average, I would estimate. This > should be handled easily, but instead it's gagging on it and the > requests are stacking up. Something is stalling the named process. Try to run "strace -T -f -p 4509" (4509 is the PID for the named process) and see where named spends its time. The top output you quoted suggests that the process is not spinning in user space. ___ 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: DNSSEC and CVE-2012-1033 (Ghost domain names)
* Stephane Bortzmeyer: > OK, so there is nothing that can be done at the registry level. Doesn't the DNSSEC-based mitigation rely on RRSIGs whose validity does not extend too far into the future? ___ 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: cannot resolve oppedahl.com from uspto.gov domain
* Karen Lear: > Who would be responsible for opening a trouble report to GoDaddy? > I don't understand exactly what the problem is here. The DNS operator for oppedahl.com has a contactual relationship with Godaddy, so if they open a ticket with Godaddy, that would likely match Godaddy's business processes in the best possible. -- Florian Weimer 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: cannot resolve oppedahl.com from uspto.gov domain
* Florian Weimer: > * Bill Owens: > >> On Fri, Feb 03, 2012 at 01:55:12PM +0000, Florian Weimer wrote: >>> These nameservers: >>> >>> dns2.oppedahl.com. 172800 IN A 208.109.255.50 >>> dns1.oppedahl.com. 172800 IN A 216.69.185.50 >>> >>> return SERVFAIL for EDNS0 queries. COM contains a signed delegation. >>> This configuration is not supported. It seems that BIND produces >>> a failure even if DNSSEC validation is not enabled for the view. >> >> How odd. . . it doesn't look that way from here: >> >> [littledebian:~] owens% dig oppedahl.com soa +norec +edns=0 @216.69.185.50 > > The exact same command line results in SERVFAIL for me. It depends on the source IP address. I tested from about a dozen source addresses. There is a pattern (most of the time, one address works, but the neighboring ones do not), but it it's not completely obvious. It could be the result of DDoS mitigation gone wild, or per-source load sharing redirecting part of the traffic to a broken instance. -- Florian Weimer 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: cannot resolve oppedahl.com from uspto.gov domain
* Bill Owens: > On Fri, Feb 03, 2012 at 01:55:12PM +0000, Florian Weimer wrote: >> These nameservers: >> >> dns2.oppedahl.com. 172800 IN A 208.109.255.50 >> dns1.oppedahl.com. 172800 IN A 216.69.185.50 >> >> return SERVFAIL for EDNS0 queries. COM contains a signed delegation. >> This configuration is not supported. It seems that BIND produces >> a failure even if DNSSEC validation is not enabled for the view. > > How odd. . . it doesn't look that way from here: > > [littledebian:~] owens% dig oppedahl.com soa +norec +edns=0 @216.69.185.50 The exact same command line results in SERVFAIL for me. Various protocol-specific traceroutes suggests that I'm hitting the Godaddy servers hosted close to Level3 in Washington DC. -- Florian Weimer 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: cannot resolve oppedahl.com from uspto.gov domain
* Karen Lear: > Beginning sometime within the past few days, uspto.gov domain cannot > resolve oppedahl.com domain, but can resolve it from almost everywhere > else. These nameservers: dns2.oppedahl.com. 172800 IN A 208.109.255.50 dns1.oppedahl.com. 172800 IN A 216.69.185.50 return SERVFAIL for EDNS0 queries. COM contains a signed delegation. This configuration is not supported. It seems that BIND produces a failure even if DNSSEC validation is not enabled for the view. -- Florian Weimer 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: Defense against a client?
* Chuck Anderson: > Unfortunately, these sorts of per-IP limiting are going to become more > and more inappropriate with the likes of Carrier Grade NATs, since > there will be many subscribers sharing a single public IP address. > You may end up causing performance problems for legitimate traffic. Fortunately, this is not that relevant because it's not really feasible to run largish DNS resolvers behind port-based NAT anyway (in part due to source port randomization). 8-) -- Florian Weimer 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: which NS record will be cached?
* MontyRee: > so, on resolving DNS, which NS record TTL will be cached generally? > 172800 or 345600? The child RRset will be cached and returned in client queries. However, it has been suggested to check with the parent servers that the delegation is still unchanged when it expires, so that you don't get stuck eternally on name servers which serve a stale copy of the zone after a delegation change. I'm not sure that this is implemented in BIND. -- Florian Weimer 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: NAPTR Catch-all
> I did try the following: > > 7.7.7.5.2.1.4.4.9.9.8.1.2.* The "*" wildcard must be the first label. ___ 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: NAPTR Catch-all
> 7.7.7.5.2.1.4.4.9.9.8.1.2.INNAPTR10010"u" "E2U+sip" > "!(^.*$)!sip:2799820784000132" .; Testing This isn't a wildcard, so it will not match as a wildcard. Can you provide a few example RRs which you want to synthesize using wildcards? It's not clear (to me at least) what you're trying to do. There is a good chance that you have to change the regexp part of the NAPTR record. ___ 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: View-specific logging
* JINMEI Tatuya / 神明達哉: > At Mon, 02 Jan 2012 09:42:29 +, > Florian Weimer wrote: > >> I would like to switch on query logging for specific views only. Is >> this possible using BIND 9.7 (or any other BIND version, for that >> matter)? > > As far as I know it's not possible with any version of BIND 9 (and not > only for query logging but also for logging in general). Adding "querylog yes/no" to the view configuration doesn't look too hard because the query logging code already has got a pointer to the dns_view structure. A general per-view logging configuration is certainly more difficult to implement. -- Florian Weimer 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
View-specific logging
I would like to switch on query logging for specific views only. Is this possible using BIND 9.7 (or any other BIND version, for that matter)? The "querylog" option does not seem to apply to views, and it does not appear to be possible to filter based on view in the "logging" phrase. -- Florian Weimer 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: bind 9.2.1 assertion failure
* Mark Andrews: > BIND 9.2.1 was released May 2002 and is no longer supported. Uhm, there are multiple sources for BIND support. At least one still provides some coverage for BIND 9.2. ___ 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: trigger point for new bug
* Jack Tavares: > Thank you again. And I agree that upgrading is the best option, however > I was looking for any possible mitigations to the problem for the > (unfortunately unavoidable) period of time it will take vendors > to provide patched bind servers. I don't think it's possible to filter the triggering packets without putting some special-purpose code on the device, and then you can just patch out the assert. -- Florian Weimer 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: another INSIST bug?
* Matus UHLAR: > Is this different appearance of the bug fixed 2 days ago, or completely > new bug? Looks rather like a different problem. Does the machine have ECC RAM? It could be a hardware issue. -- Florian Weimer 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: BIND 9.7.3-P3 crash on multiple cashing servers
* Samer Khattab: > I found the following in the logs: > > 16-Nov-2011 08:26:58.724 query.c:1781: INSIST(! > dns_rdataset_isassociated(sigrdataset)) failed, back trace Is this from a version which was compiled from sources provided by ISC, or some distribution version? -- Florian Weimer 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: bind-9.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed
> To my surprise, I had several DNS servers running BIND 9.8.1 all fail > at about the same time with this assertion failure in query.c, on line > 1895. Have you compiled BIND from the original ISC sources, or do you use a distribution version? -- Florian Weimer 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: Reason for Limited number of Root DNS Servers
* Gaurav Kansal: > As root DNS are running in anycast so number is not an issue at all. But I > don't understand where exactly is this limitation exists??? The limitation does not exist, otherwise it would not have been possible to add IPv6 addresses to the priming response. -- Florian Weimer 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: Fix for CVE-2006-2073
* Mark Andrews: > Access Vector: Network exploitable > Access Complexity: Low > Authentication: Not required to exploit > Impact Type:Allows disruption of service > > I fail to see how this could ever have been classified as > Access Complexity: Low. I believe the CVSS scoring for those old entries was generated semi-automatically. There's also very little public information available about this issue. > Looking at the CVE it looks like this bug fix contains the correction. > > 2013. [bug] Handle unexpected TSIGs on unsigned AXFR/IXFR > responses more gracefully. [RT #15941] > >> What was the first BIND version that fixed it? > > 9.2.7, 9.3.3, 9.4.0. Thanks, this is helpful. I've adjusted Debian's records. ___ 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
Fix for CVE-2006-2073
I've noticed that nobody seems to have accurate information about CVE-2006-2073 on file. This was a vulnerability in handling TSIG-based authentication *after* authentication, so it wasn't a high priority issue. What was the first BIND version that fixed it? ___ 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 Weimer 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: EDNS request problem on TTL=0 data
* Paul Wouters: > 1 Is this problem happening because EDNS failure is not remembered for > forwarders? There is no realiable way to detect EDNS support in forwarders, so there isn't anything to remember, really. Sadly, the situation with authoritative servers is not much better. -- Florian Weimer 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: Root Hints Data File for a .local Domain
* Tony MacDoodle:
> So in the named.conf file I can get rid of the following:
>
> zone "." { type hint; file "db.cache"; };
Yes, I think 9.6 has built-in root hints. The zone contents is
ignored, except for the NS records and the associated addresses
(because of "type hint" instead of "type master").
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Root Hints Data File for a .local Domain
* Tony MacDoodle: > 2) Do I need it at all for a local domain No, configuring a zone using the "zone" statement on all resolvers is sufficient. If the resolver knows about authoritative data, it will not try to fetch it from the Internet. You should reconsider using "local", though. Some clients treat it as a special string. Use a real domain name, or something under "loc" or "corp". -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root zone initial key in bind.keys
* Kevin Oberman: >> If anyone is out there who wants to be using ISC DLV but does not want to >> use the root key, comment the root key out of bind.keys. > > I would really hoe that the set described above is an empty set. It's not. We know because there is a zone availability issue in BIND 9.6-ESV which manifests if you use a DLV-only configuration, and people run into it and report problems. (BTW, what's the support status of 9.6-ESV?) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.7.2 not forward CNAMEDed domain names
* Drunkard Zhang: > My capture command: tcpdump -s 0 -nnnvvv -w 360.cn-`date +%Y%m%d`.pcap > udp port 53 > > 17:59:36 ~ $ dig +nocmd speedtest.360.cn @211.161.192.1 +multiline > +noall +answer > speedtest.360.cn. 215 IN CNAME speedtest.360.cn.cloudcdn.net. > speedtest.360.cn.cloudcdn.net. 325 IN CNAME cloud010005.cachecn.com. > cloud010005.cachecn.com. 368 IN A 61.155.141.28 > > but bind just resolved cloud010005.cachecn.com again. With a cold cache, I see this: [1au] A? speedtest.360.cn. ar: . OPT UDPsize=4096 OK (45) [1au] A? speedtest.360.cn.cloudcdn.net. ar: . OPT UDPsize=4096 OK (58) [1au] A? cloud010005.cachecn.com. ar: . OPT UDPsize=4096 OK (52) I suspect that the middle CNAME is still in cache in your case. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.7.2 not forward CNAMEDed domain names
* Drunkard Zhang: > 2011/2/22 Florian Weimer : >> * Drunkard Zhang: >> >>> The upstream DNS server 211.161.192.1 did responsed correctly, by >>> analysis via tcpdump. But why bind didn't use THE RESPONSE, but >>> resolves again from root-servers. >> >> Unfortunately, the information provided by 211.161.192.1 must be >> discarded because that is server is not authoritative for cachecn.com. >> From your resolver's perspective, it is a totally unrelated domain >> name. >> > Thanks! So bind can accept second hand answer, but won't accept third > hand (or more) answer? It shouldn't accept the second CNAME, either. Are you sure that it does? It's probably the same globally, so it's not visible from the cache contents. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.7.2 not forward CNAMEDed domain names
* Drunkard Zhang: > The upstream DNS server 211.161.192.1 did responsed correctly, by > analysis via tcpdump. But why bind didn't use THE RESPONSE, but > resolves again from root-servers. Unfortunately, the information provided by 211.161.192.1 must be discarded because that is server is not authoritative for cachecn.com. >From your resolver's perspective, it is a totally unrelated domain name. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.3 is now available.
* Dennis Clarke: > I would think a posix speec compliant implementation would work anywhere. BIND uses its own locking mechanisms, using machine code insertions. For fringe some platforms, they do not seem to be correct. i386 or amd64 should be fine, though. (Switching to GCC's synchronization primitives would probably be quite easy, at least if you can figure out which ordering semantics are expected. The machine code insertions already depend on GCC, after all.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Akadns and Bind
* Tory M. Blue: > [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com +trace Please use "dig @problemserver.net www.yahoo.com +trace +norecurse +dnssec", to match more closely the queires that BIND would send. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0b1 Released Today
* JINMEI Tatuya / 神明達哉: > Paul Wouters wrote: >> Does this work with DNSSEC if one loads an explicit trust anchor, even >> if in the "world view" the trust anchor is missing? > > I'm afraid I don't understand the question. Could you be more > specific, e.g., by using the above example.com example? I think Paul is wondering if it works with the DENIC testbed. 8-) The forward hack does not work reliable for DNSSEC islands, IIRC. (I assume that static-stub zones result in RD=0 queries, so they should work in such a scenario.) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: caching of expired RRSIG's ?
* Marc Lampo: > I agree for the consequence of those "cache misses". > But doesnot that mean that RFC4035 needs amended to state : > "remove atomic entry if *all* its RRSIGs get invalid" > (because now it states : any = "at least one") It's about the TTL on the RRSIG RRset, not the signature validity period. Conceptually, this TTL applies to the RRset as a whole, not individual records, even though on the wire, it is repeated for each record. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: caching of expired RRSIG's ?
* Marc Lampo: > If anybody disagrees with this interpretation, > and interprets it like expired RRSIG's *must* be deleted from a cache, > would you be so kind to share the reference(s) any RFC's on which you base > your interpretation. You need to cache expired RRSIGs for some time, or else every DO=1 query for the relevant record triggers a cache miss, which would be problematic. This negative caching of DNSSEC-related failure is optional according to the RFC, but is required as a practical matter in implementations suitable for large-scale deployment. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.2-P2 is now available.
* Mark Andrews: > * If BIND, acting as a DNSSEC validating server, has two or more >trust anchors configured in named.conf for the same zone (such as >example.com) and the response for a record in that zone from the >authoritative server includes a bad signature, the validating >server will crash while trying to validate that query. Does this change need backporting to 9.6-ESV? Is an isolated patch available? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Rebinding Prevention for the Weak Host Model Attacks
* Bradley Falzon: > Craig Heffner's version of the DNS Rebinding attack, similar to all > DNS Rebinding attacks, requires the DNS Servers to respond with an > Attackers IP Address as well as the Victims IP Address, in a typical > Round Robin fashion. Previous attacks would normally have the Victims > IP Address to be their Private IP. For which protocols is this supposed to work? Why would a security-minded web application serve content under a name it knows cannot be its own? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: T_ANY
* Glenn English: >>> Hi. This is the qmail-send program at yahoo.com. > Both servers are Debian lenny, 'named -v' says BIND 9.5.1-P3, and > bind's config check says it's OK. But it has nothing to do with any > of that, I think, because the query works from inside. Have you compiled qmail yourself? Then you probably forgot to apply this patch: | qmail (1.03-1) unstable; urgency=low [...] | * Applied patch to dns.c to allow e-mail to deliver correctly to systems where | their DNS size is greater > 512. Fixes "CNAME Lookup Failure" error when | delivering mail to aol.com | | -- Jon Marler Sat, 29 May 1999 12:33:00 +0100 -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL for some domains on some servers
* Kevin Darcy: > I'm not sure those recommendations apply as strongly as they used > to. Now we have views and (if the original poster were to upgrade to > 9.4.x or higher) fine-grained control over access to cached data. Views are probably okay. Access control is insufficient, especially if you register domains on behalf of customers. Typically, you need to activate these domains prior to obtaining the delegation, and the recursor will return incorrect data when you fail to actually get the delegation. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
* Sam Wilson: > Has anyone found any uz5* servers out there yet? node.pk, dempsky.org has such name servers. I thought there were more. Has the magic prefix changed? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
* Eugene Crosser: > Right now, as far as I am concerned, the main obstacle to more > widespread adoption on DNSSEC is the lack of procedure to establish > trust between your zone and the TLD. There's no standard procedure for NS and glue management, either, and it still seems to work quite well. 8-) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 overloaded, recursive clients and timeout.
* Cedric Lejeune: > you... Do you have any hint that would help me to track down what is > wrong? You should check if this isn't the result of some DNSBLs blocking your resolver. The SORBS result look suspicious. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET & KEYSET
* Chris Thompson: >>Parent zone policies vary. Some require DS RRs, some DNSKEY RRs. >>Demanding DNSKEY RRs can prolong the life of signature schemes with >>certain weaknesses (which might be helpful at some point in the >>future). > > I take it you refer there to the digest type field in the DS record? No, there are attacks on hash functions which cause a collision by extending two non-colliding messages, that is, for given p_1, p_2, find s_1 and s_2 such that h(p_1 s_1) = h(p_2 s_2). If you demand DNSKEYs, the attacker lacks direct control over the s_i because of the additional hashing step, requiring a much stronger attack. (In an attack, p_1 and p_2 would contain different domain names, for the victim name and another name which the attacker can register. The parent zone will sign p_1 s_1, and the attacker will use p_2 s_2, for which the signature on p_1 s_1 is also valid because of the hash collision. AFAICT, this is just a minor variant of the well-published attack on MD5 certificates.) This is all theoretical because no such attacks are currently known against SHA-1. In retrospect, the fact that all major certification-like schemes require something much stronger than second preimage resistance from the underlying hash function seems like a blunder of WEP-like proportions. Fortunately, there are workarounds for DNSSEC and X.509 (you don't even need the DNSKEYs if you employ randomized hashing, and there's enough wiggle room for that, as discussed on the namedroppers list). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET & KEYSET
* prock: > Is there a tool/process to verify if the parenet domain has DSSET, > KEYSET, or keys in place for the child domain? Thanks. No, such parent domain policies are not obvious from looking at the DNS. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET & KEYSET
* prock: > In a DNSSEC compliant world (I know we're not there yet) we need to > give a copy of our DSSET and KEYSET to our parent domain. Please > confirm that is an accurate statement. Parent zone policies vary. Some require DS RRs, some DNSKEY RRs. Demanding DNSKEY RRs can prolong the life of signature schemes with certain weaknesses (which might be helpful at some point in the future). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CLASS support
> I understand that. But I need to use Private Use classes. The question > is how do I do it? Use CLASS999 and similar identifiers (just like TYPE999 for types). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Zone updated in one view served from another view
Will BIND 9.5 do the right thing if a zone file is configured in one view, permitting updates through Dynamic DNS, and included in another view (without allowing updates)? If the direct approach (listing the zone file twice) does not work, is there some way to achieve this by other means? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Round robin load distribution among servers does not work properly
* Mallappa Pallakke: > Can anybody tell me why this limitation and is there any sollution to > resove this problem? Does your dig call result in two lookups behind the scenes, perhaps? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how bind supports multi-processors?
* JINMEI Tatuya / 神明達哉: > That's an optional feature, even if it's enabled by default when found > to be available by autoconf. If the atomic operations cause stability > problems, you can disable them by rebuilding BIND9 with --disable-atomic. Would it be possible to disable them by default on architectures where the intrinsics haven't been reviewed by someone familiar with the platform, or tested very extensively? We keep running into those issues on fringe architectures. 8-/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how bind supports multi-processors?
* Ralf Peng: > Is threads stable enough in product use of Bind? It's stable on mainstream architectures. GNU/Linux on i386 and amd64 is fine in general. GNU/Linux on hppa, mips(el), ia64, and others is problematic. The hppa instability could be due to the lack of a stable SMP kernel. The ia64 issues seem to be a genuine BIND 9 issue. Part of the problem is that BIND contains its own set of wrappers for atomic CPU operations, instead of using GCC's intrinsics or libatomicops. Last time I tried to look at this, I couldn't find a clear description of the flavor of atomic instructions required by BIND (which barriers are implied etc.), so it's very difficult to make the change. I can't test on ia64 and sparc, either. The x86-derived architectures are just too forgiving about errors in this area to be useful test cases. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange 9.6.0-P1 issue
* c0re dumped: > I don't what could it be, but I'm getting tons of > > "no valid RRSIG resolving 'www.xyz.xom/A/IN': X.X.X.X.#53" You need to provide actual DNS names and IP addresses, otherwise we won't be able to help you. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [dnssec] issue resolving unsigned child zone using DLV
* Shane W.: >> There should be a signed NSEC record showing that the delegation is, >> indeed, unsigned. > > Well we're using nsec3 if that matters but if it's not > being signed correctly, is that likely a bug with how we're > calling dnssec-signzone? Ah, in that case, you probably haven't upgraded some of the authoritative servers to BIND 9.6. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [dnssec] issue resolving unsigned child zone using DLV
* Shane W.: > Bind outputs: > Mar 14 12:39:13 continuum named[2168]: no valid RRSIG resolving > 'odyssey.csy.ca/NS/IN': 72.55.146.170#53 > Mar 14 12:39:13 continuum named[2168]: no valid RRSIG resolving > 'odyssey.csy.ca/NS/IN': 96.49.174.96#53 > Mar 14 12:39:13 continuum named[2168]: no valid RRSIG resolving > 'odyssey.csy.ca/NS/IN': 96.49.174.96#53 > Mar 14 12:39:13 continuum named[2168]: no valid RRSIG resolving > 'odyssey.csy.ca/NS/IN': 72.55.146.170#53 > Mar 14 12:39:13 continuum named[2168]: no valid RRSIG resolving > 'odyssey.csy.ca/NS/IN': 72.55.146.170#53 > Mar 14 12:39:13 continuum named[2168]: no valid RRSIG resolving > 'odyssey.csy.ca/NS/IN': 96.49.174.96#53 I think the csy.ca zone has not been correctly signed: ; <<>> DiG 9.5.1-P1 <<>> @dme6.ns.csy.ca. odyssey.csy.ca +norecurse +dnssec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27092 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;odyssey.csy.ca.IN A ;; AUTHORITY SECTION: odyssey.csy.ca. 86400 IN NS springtide.ca. odyssey.csy.ca. 86400 IN NS odyssey.ns.csy.ca. ;; ADDITIONAL SECTION: odyssey.ns.csy.ca. 3600IN A 96.49.174.96 odyssey.ns.csy.ca. 3600IN RRSIG A 7 4 3600 20090413192159 20090314192159 22004 csy.ca. WgtWJmq+fgkm7rH+9Dw996l/6M+qEwW6CQPcvTPZoF/kO6JlzrRYpuLK em8SMDTfjPZFtyvaMOYY1bQxj8M/WQ== ;; Query time: 737 msec ;; SERVER: 64.246.42.203#53(64.246.42.203) ;; WHEN: Sun Mar 15 12:44:39 2009 ;; MSG SIZE rcvd: 211 There should be a signed NSEC record showing that the delegation is, indeed, unsigned. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS lookup problems specific the Facebook domains
* Rob Tanner: > I'm trying to figure out if this is my problem or a Facebook problem. > The first issue was with facebookmail.com. The cache entry would > become corrupt and I would have to clear cache to get things back to > working again. Since facebookmail.com resolves to a single IP > address, my work around was to make my internal DNS authoritative for > it and the problem went away. You should have investigated this. Caches don't corrupt so easily. There might be someone tampering with your network. For example, it seems that the (PIX?) firewall which is in front of the resolver used by your incoming mail relay destroys source port randomization and assigns ports sequentially. If you have a similar setup for your end-user resolvers, you might be exposed to significantly increased cache poisoning risk. > A week ago, DNS lookups for facebook.com failed completely. Even > restarting the DNS service didn't fix the problem. Currently, and as > a temporary fix only, I am forwarding facebook,com lookups to an > off-campus server which does not seem to have the problem. And now, > as of last night, lookups to fbcdn.net (which apparently hosts > stylesheets) fail completely and I've implemented the same forwarding Have you got any log entries you can share? What does "dig facebook.com +trace +norecurse +all" show on the name server? Can you dump the name server cache using "rndc dumpdb" and extract the relevant records? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
