* 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
>
* 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
* 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
* 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
* 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, 30Nov 11 13:07:25 named[8349]:..., 107,
MSG_NOSIGNAL) = 107 0.015232
[pid 8353] send(3, 30Nov 11 13:07:25 named[8349]:..., 103,
[pid 8353] ... send
* 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
* Bill Owens:
On Fri, Feb 03, 2012 at 01:55:12PM +, 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
* Florian Weimer:
* Bill Owens:
On Fri, Feb 03, 2012 at 01:55:12PM +, 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
processes in the best possible.
--
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
.
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 Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
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 Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721
7.7.7.5.2.1.4.4.9.9.8.1.2.INNAPTR10010u 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
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
* JINMEI Tatuya / 神明達哉:
At Mon, 02 Jan 2012 09:42:29 +,
Florian Weimer fwei...@bfk.de 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
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
* 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
* 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
* 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
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?
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
* 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
treat it as
a special string. Use a real domain name, or something under loc or
corp.
--
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
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 Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133
is not authoritative for cachecn.com.
From your resolver's perspective, it is a totally unrelated domain
name.
--
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
* Drunkard Zhang:
2011/2/22 Florian Weimer fwei...@bfk.de:
* 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
)
[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 Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe
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 Weimerfwei...@bfk.de
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 Weimerfwei...@bfk.de
BFK edv-consulting GmbH http
* JINMEI Tatuya / 神明達哉:
Paul Wouters p...@xelerance.com 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
* 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
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 Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
Marler jmar...@debian.org Sat, 29 May 1999 12:33:00 +0100
--
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
* 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
-)
--
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
___
bind-users mailing list
bind-users@lists.isc.org
* 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 Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
of signature schemes with
certain weaknesses (which might be helpful at some point in the
future).
--
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
* 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 Weimerfwei...@bfk.de
BFK edv-consulting GmbH http
list).
--
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
___
bind-users mailing list
bind-users
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
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
* 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
* 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 upgraded
44 matches
Mail list logo
