* 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
> offi
* 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 vulnera
* 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 respons
* 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]
* 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 lin
* 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/b
'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
___
Pl
* 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
* 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 SERV
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
mate 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
o 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
> 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
> 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)
* 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 i
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/li
* 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
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 Kar
* 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.
* 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?
--
Fl
> 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
* 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.
--
Flo
* 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 entri
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?
__
soning 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/listinf
* 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.
"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-
al", 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
ility 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
loudcdn.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
* 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.
&
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
nization 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
* 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
* 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 examp
t 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ß
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 deploymen
* 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 v
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.
e" 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
___
* 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
* 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-
ork 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
* 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@
iggle 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
__
* 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.
olong 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: +4
> 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/
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?
* 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.i
* 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
* 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
* 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
* 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 upgra
* 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 R
* 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
> addres
56 matches
Mail list logo
