This is partially addressed in the upcoming maintainence release.
diff --git a/lib/bind9/check.c b/lib/bind9/check.c
index 5d95eda..5891255 100644
--- a/lib/bind9/check.c
+++ b/lib/bind9/check.c
@@ -1324,8 +1324,10 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t
*voptions,
{
Hi All,
I am in the process of migrating all of our client facing resolver hosts back
to BIND (from unbound) and have hit a roadblock.
I wanted to confirm if I have missed something in my BIND configuration or I
have hit some sort of limitation in BIND.
It appears as if BIND is ignoring the sta
On 8/23/2012 3:49 PM, Kevin Darcy wrote:
> Sorry, I meant to say that it's pretty clear that it *restricts* what a
> Service Label may contain. It's even a "MUST".
Sure, but you're omitting the (typically unstated) part of the MUST, "a
compliant implementation." So it depends on the OP's purpose.
On 8/23/2012 6:46 PM, Kevin Darcy wrote:
On 8/23/2012 6:09 PM, Kevin Oberman wrote:
On Thu, Aug 23, 2012 at 8:52 AM, Nikolay Shaplov wrote:
Hi!
I am trying to write a validator for name field of SRV record, and I
met
several issues I can not understand. May be you can help me with that.
0.
On 8/23/2012 6:09 PM, Kevin Oberman wrote:
On Thu, Aug 23, 2012 at 8:52 AM, Nikolay Shaplov wrote:
Hi!
I am trying to write a validator for name field of SRV record, and I met
several issues I can not understand. May be you can help me with that.
0. Bind does not really validate name of SRV r
On Thu, Aug 23, 2012 at 8:52 AM, Nikolay Shaplov wrote:
> Hi!
>
> I am trying to write a validator for name field of SRV record, and I met
> several issues I can not understand. May be you can help me with that.
>
> 0. Bind does not really validate name of SRV record:
>
> _te__st_._te--st!?.rrr!e
Hi!
I am trying to write a validator for name field of SRV record, and I met
several issues I can not understand. May be you can help me with that.
0. Bind does not really validate name of SRV record:
_te__st_._te--st!?.rrr!e
is considered to be correct record. (BIND 9.7.3) So I can not use
In our case, 90% of the dns-sd queries were for the 192.168 network.
These are from 1 client:
DNS C db._dns-sd._udp.0.158.168.192.in-addr.arpa. Internet PTR ?
DNS C dr._dns-sd._udp.0.158.168.192.in-addr.arpa. Internet PTR ?
DNS C lb._dns-sd._udp.0.158.168.192.in-addr.arpa. Internet PTR ?
DNS C cf.
is there someway to alleviate this?
On 8/23/12, Manson, John wrote:
> Good explanation of Service Discovery:
> http://www.dns-sd.org/
>
> Also, Bonjour is a big offender:
> http://en.wikipedia.org/wiki/Bonjour_%28software%29
> A lot of Apple apps use it like itunes.
>
> -Original Message-
Good explanation of Service Discovery:
http://www.dns-sd.org/
Also, Bonjour is a big offender:
http://en.wikipedia.org/wiki/Bonjour_%28software%29
A lot of Apple apps use it like itunes.
-Original Message-
From: bind-users-bounces+john.manson=mail.house@lists.isc.org
[mailto:bind-use
Maybe blocking access by that IP will force the customer's tech folks to
contact you?
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of
wbr...@e1b.org
Sent: Thursday, August 23, 20
Elvind wrote on 08/23/2012 09:18:06 AM:
> Yeah, now I'm just wondering which OS / application / malware / whatever
> could be responsible for this :)
Someone trying to use ZeroCOnf: http://zeroconf.org I believe Macs come
configured to use it by default, Linux and Windows can be configured to
Torsten Segner wrote:
> these seem to be DNS Service Discovery requests and yes, we see loads of
> them on our servers.
Yeah, now I'm just wondering which OS / application / malware / whatever
could be responsible for this :)
(no, the client isn't directly under my control, it belongs to some cu
Am Thu, 23 Aug 2012 13:43:32 +0200
schrieb "Eivind Olsen" :
> Hello.
>
> I haven't seen this before.. I'm currently seeing someone (1 ip address)
> do about 2.1 million queries / hour where a majority of the queries seem
> to be:
>
> b._dns-sd._udp.0.129.16.172.in-addr.arpa IN PTR +
> db._dns-sd
Hello.
I haven't seen this before.. I'm currently seeing someone (1 ip address)
do about 2.1 million queries / hour where a majority of the queries seem
to be:
b._dns-sd._udp.0.129.16.172.in-addr.arpa IN PTR +
db._dns-sd._udp.0.129.16.172.in-addr.arpa IN PTR +
r._dns-sd._udp.0.129.16.172.in-addr.
15 matches
Mail list logo