Re: rpz_rewrite(): failure

2023-05-15 Thread Wilfred Sarmiento via bind-users 
Hi Darren,

Sorry for late response, see below scrubbed config;

We updated the bind to 9.18.14 but still experienced the same issue.


controls {

inet 127.0.0.1 port 953 allow {

127.0.0.1/32;

} keys {

"rndc-key";

};

};

logging {

channel "default_syslog" {

file "/var/local/syslog" versions unlimited size 2147483648;

severity warning;

print-time yes;

print-severity yes;

print-category yes;

};

category "resolver" {

"default_syslog";

};

category "queries" {

"default_syslog";

};

category "lame-servers" {

"null";

};

};

options {

directory "/var/local/bind";

recursive-clients 1;

statistics-file "/var/local/bind/etc/named.stats";

version "Query Not Allowed.";

allow-recursion {

"globeIP";

};

response-policy {

zone "rpzblacklisted";

};

synth-from-dnssec no;

allow-query {

"globeIP";

};

zone-statistics yes;

};

key "rndc-key" {

algorithm "hmac-md5";

secret
"";

};

server fe80::/10 {

bogus yes;

};

zone "." in {

type hint;

file "namedb/db.cache";

};

zone "localhost" IN {

type master;

file "namedb/db.localhost";

};

zone "0.0.127.in-addr.arpa" in {

type master;

file "namedb/db.127.0.0";

notify no;

};

zone "rpzblacklisted" {

type slave;

file "/var/local/bind/db.rpzblacklisted";

masters {

x.x.x.x;

};

};

Thank you,
Wil

On Wed, May 10, 2023 at 6:31 PM Darren Ankney 
wrote:

> Hi Wilfred,
>
> You might want to consider updating your BIND server.  The latest
> 9.18.x is 9.18.14.  There have been many fixes between 9.18.2 and
> 9.18.14 as can be seen here:
> https://bind9.readthedocs.io/en/v9.18.14/notes.html  Also, when
> testing, you may want to consider using dig as it provides far more
> detail.  nslookup usage is no longer recommended as it has been
> deprecated.
>
> As to this specific issue, I'm not sure.  You might get more help from
> others, however, if you share your configuration.  You can get a
> configuration scrubbed of keys using `named-checkconf -px`
>
> Thank you,
>
> Darren Ankney
>
> On Tue, May 9, 2023 at 9:39 AM Wilfred Sarmiento via bind-users
>  wrote:
> >
> > Hi Bind Users,
> >
> > Any one familiar with the error we encountered on DNS BIND 9.18.2 Ubuntu
> for DNS Caching, below;
> >
> > We are using RPZ for redirecting domains (porn sites) where we already
> have 20k+ entries.
> > The domain (globem2m.com.ph) from below logs is not in the RPZ list but
> was processed for RPZ QNAME rewrite, based on the logs, and query to that
> domain results to SERVFAIL.
> > The issue is isolated to several domains only including globem2m.com.ph,
> all other queries to different domains are successful.
> >
> > To resolve this issue, we have to flush cache or restart the BIND
> service.
> >
> > root@bind# nslookup globem2m.com.ph 
> >
> >
> > ** server can't find globem2m.com.ph: SERVFAIL
> >
> >
> > Trace logs:
> >
> > : query (cache) 'globem2m.com.ph/A/IN' approved
> >
> > : rpz QNAME rewrite globem2m.com.ph stop on qresult in rpz_rewrite():
> failure
> >
> > : query failed (failure) for globem2m.com.ph/IN/A at query.c:7657
> >
> > fetch completed at resolver.c:4053 for globem2m.com.ph/A in 0.00:
> failure/success [domain:com.ph
> ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
> >
> > : reset client
> >
> > : servfail cache hit globem2m.com.ph/A (CD=0)
> >
> > : query failed (SERVFAIL) for globem2m.com.ph/IN/A at query.c:6949
> >
> > : reset client
> >
> >
> > Thank you,
> > Wil
> >
> >
> >
> >
> > This e-mail message (including attachments, if any) is intended for the
> use of the individual or the entity to whom it is addressed and may contain
> information that is privileged, proprietary, confidential and exempt from
> disclosure. If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify the sender and delete this E-mail message immediately.
> >
> > --
> > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
> >
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> inf

rpz_rewrite(): failure

2023-05-09 Thread Wilfred Sarmiento via bind-users 
Hi Bind Users,

Any one familiar with the error we encountered on DNS BIND 9.18.2 Ubuntu
for DNS Caching, below;

We are using RPZ for redirecting domains (porn sites) where we already have
20k+ entries.
The domain (globem2m.com.ph) from below logs is not in the RPZ list but was
processed for RPZ QNAME rewrite, based on the logs, and query to that
domain results to SERVFAIL.
The issue is isolated to several domains only including globem2m.com.ph,
all other queries to different domains are successful.

To resolve this issue, we have to flush cache or restart the BIND service.

root@bind# nslookup globem2m.com.ph 


** server can't find globem2m.com.ph: SERVFAIL

Trace logs:

: query (cache) 'globem2m.com.ph/A/IN' approved

: rpz QNAME rewrite globem2m.com.ph stop on qresult in rpz_rewrite():
failure

: query failed (failure) for globem2m.com.ph/IN/A at query.c:7657

fetch completed at resolver.c:4053 for globem2m.com.ph/A in 0.00:
failure/success [domain:com.ph
,referral:0,restart:1,qrysent:0,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]

: reset client

: servfail cache hit globem2m.com.ph/A (CD=0)

: query failed (SERVFAIL) for globem2m.com.ph/IN/A at query.c:6949

: reset client

Thank you,
Wil

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: SRV Record Server Availability

2021-01-06 Thread Wilfred Sarmiento via bind-users 
Hi Tale, Happy new year!

Your understanding is correct, i just thought that SRV can detect whose
server is alive so it can choose and provide an answer with the available
Server.

Thank you!



On Tue, 5 Jan 2021, 23:53 tale  wrote:

> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users
>  wrote:
> > Is DNS Bind SRV record can detect the Server's availability? If yes, how?
>
> Could you provide more information about your goal?  I don't fully
> understand the question.
>
> For my reading, the answer is basically no, in that an SRV record just
> provides data about where.a particular service can be found.  It's up
> to other systems to fetch that data and interpret it, including
> whether that service is actually available at the given endpoint.  In
> its typical operation, BIND will just take whatever name and port the
> zone administrator said to provide for that SRV record, and not do any
> sort of availability checks on it.
>
> However, if you go deep into a far more complicated, custom use of
> BIND, you could set up a process that monitors the availability and
> changes the SRV record accordingly.
> --
> tale
>

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

SRV Record Server Availability

2021-01-05 Thread Wilfred Sarmiento via bind-users 
Hi,

Is DNS Bind SRV record can detect the Server's availability? If yes, how?

Thank you,
Wil

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Query failed (timed out)

2019-11-06 Thread Wilfred Sarmiento via bind-users 
Thank you Ondrej.
Hope this issue will reach Barclays Domain admin.

Thank you all for the help and advise.


On Wed, 6 Nov 2019, 18:50 Ondřej Surý  wrote:

> Hi Wilfred,
>
> BIND is not broken as Mark already pointed out, so we have no plan on
> fixing this.
>
> The DNS load-balancers (most probably) that Barclays has deployed need to
> be
> fixed to be RFC compliant.
>
> Not to mention that dropping the queries is always **BAD** as it opens a
> bigger
> window to spoofing attacks for off-path attacker.
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 6 Nov 2019, at 09:18, Wilfred Sarmiento via bind-users <
> bind-users@lists.isc.org> wrote:
> >
> > Hi Mark,
> >
> > The workaround works very well, i also got the same response from Daniel
> of Switch.
> >
> > Thank you very much!
> > Wil
> >
> >
> > On Wed, Nov 6, 2019 at 3:52 PM Mark Andrews  wrote:
> > The DNS servers for federate-secure.glbaa.barclays.com are *broken*
> which
> > is what federate.secure.barclays.com points to.  They do not respond to
> > queries with EDNS options present and named sends a DNS COOKIE EDNS
> option
> > by default.
> >
> > You can work around this by specifying
> >
> > server 157.83.102.245 { send-cookie no; };
> >
> > and similarly for all the other IP addresses of the GLB but the real fix
> > is for Barclays to deploy RFC compliant DNS servers.  Their servers
> nominally
> > support EDNS and unknown EDNS options are supposed to be ignored, not
> cause
> > the query to be dropped.
> >
> > % dig federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> >
> > ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62156
> > ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;federate-secure.glbaa.barclays.com. IN A
> >
> > ;; ANSWER SECTION:
> > federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
> >
> > ;; Query time: 356 msec
> > ;; SERVER: 157.83.102.245#53(157.83.102.245)
> > ;; WHEN: Wed Nov 06 18:49:20 AEDT 2019
> > ;; MSG SIZE  rcvd: 79
> >
> > % dig federate-secure.glbaa.barclays.com @157.83.102.245
> >
> > ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com @157.83.102.245
> > ;; global options: +cmd
> > ;; connection timed out; no servers could be reached
> >
> > [beetle:~/git/bind9] marka% dig federate-secure.glbaa.barclays.com
> +nocookie @157.83.102.245
> >
> > ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20094
> > ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;federate-secure.glbaa.barclays.com. IN A
> >
> > ;; ANSWER SECTION:
> > federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
> >
> > ;; Query time: 383 msec
> > ;; SERVER: 157.83.102.245#53(157.83.102.245)
> > ;; WHEN: Wed Nov 06 18:50:19 AEDT 2019
> > ;; MSG SIZE  rcvd: 79
> >
> > %
> >
> >
> > > On 6 Nov 2019, at 18:32, Wilfred Sarmiento via bind-users <
> bind-users@lists.isc.org> wrote:
> > >
> > > Hi Bind Users,
> > >
> > > Anyone have a similar issue we are encountering with the subdomain of
> Barclays.com specifically federate.secure.barclays.com
> > > Our cache server could not resolve the said subdomain, but was able to
> resolve their root domain barclays.com and any other known domains.
> > > Debug just showed below little details of logs.
> > > That subdomain was resolvable using Google DNS and other OpenDNS.
> > >
> > > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> (x.x.x.x)
> > > client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com):

Re: Query failed (timed out)

2019-11-06 Thread Wilfred Sarmiento via bind-users 
Hi Steinar,

Noted and thank you very much.

Regards.
*Wil*


On Wed, Nov 6, 2019 at 4:21 PM  wrote:

> > The workaround works, does BIND 9.14 has a patch to resolve this? Since
> we
> > have a multiple Cache server, we need to do this every time we encounter
> > another domain that has this same issue.
>
> There's probably no patch to "resolve" this, because the correct way
> to fix the problem is at the source of the problem, typically load
> balancers which don't implement DNS correctly.
>
> You may want to read
>
> https://www.isc.org/blogs/dns-flag-day-2020/
> https://www.isc.org/blogs/dns-flag-day-was-it-a-success/
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


___
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: Query failed (timed out)

2019-11-06 Thread Wilfred Sarmiento via bind-users 
Hi Mark,

The workaround works very well, i also got the same response from Daniel of
Switch.

Thank you very much!
*Wil*


On Wed, Nov 6, 2019 at 3:52 PM Mark Andrews  wrote:

> The DNS servers for federate-secure.glbaa.barclays.com are *broken* which
> is what federate.secure.barclays.com points to.  They do not respond to
> queries with EDNS options present and named sends a DNS COOKIE EDNS option
> by default.
>
> You can work around this by specifying
>
> server 157.83.102.245 { send-cookie no; };
>
> and similarly for all the other IP addresses of the GLB but the real fix
> is for Barclays to deploy RFC compliant DNS servers.  Their servers
> nominally
> support EDNS and unknown EDNS options are supposed to be ignored, not cause
> the query to be dropped.
>
> % dig federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62156
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;federate-secure.glbaa.barclays.com. IN A
>
> ;; ANSWER SECTION:
> federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
>
> ;; Query time: 356 msec
> ;; SERVER: 157.83.102.245#53(157.83.102.245)
> ;; WHEN: Wed Nov 06 18:49:20 AEDT 2019
> ;; MSG SIZE  rcvd: 79
>
> % dig federate-secure.glbaa.barclays.com @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com @157.83.102.245
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
> [beetle:~/git/bind9] marka% dig federate-secure.glbaa.barclays.com
> +nocookie @157.83.102.245
>
> ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>>
> federate-secure.glbaa.barclays.com +nocookie @157.83.102.245
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20094
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;federate-secure.glbaa.barclays.com. IN A
>
> ;; ANSWER SECTION:
> federate-secure.glbaa.barclays.com. 30 IN A 157.83.124.48
>
> ;; Query time: 383 msec
> ;; SERVER: 157.83.102.245#53(157.83.102.245)
> ;; WHEN: Wed Nov 06 18:50:19 AEDT 2019
> ;; MSG SIZE  rcvd: 79
>
> %
>
>
> > On 6 Nov 2019, at 18:32, Wilfred Sarmiento via bind-users <
> bind-users@lists.isc.org> wrote:
> >
> > Hi Bind Users,
> >
> > Anyone have a similar issue we are encountering with the subdomain of
> Barclays.com specifically federate.secure.barclays.com
> > Our cache server could not resolve the said subdomain, but was able to
> resolve their root domain barclays.com and any other known domains.
> > Debug just showed below little details of logs.
> > That subdomain was resolvable using Google DNS and other OpenDNS.
> >
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> (x.x.x.x)
> > client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> (x.x.x.x)
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query failed (timed out) for
> federate.secure.barclays.com/IN/A at query.c:6786
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query: federate.secure.barclays.com IN A +
> (x.x.x.x)
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (
> federate.secure.barclays.com): query failed (timed out) for
> federate.secure.barclays.com/IN/A at query.c:6786
> >
> > Thank you,
> > Wil
> >
> >
> > This e-mail message (including attachments, if any) is intended for the
> use of the individual or the entity to whom it is addressed and may contain
> information that is privileged, proprietary, confidential and exempt from
> disclosure. If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify the sender and delete this E-mail message immediately.
> >
> > _

Re: Query failed (timed out)

2019-11-06 Thread Wilfred Sarmiento via bind-users 
Hi Daniel,

The workaround works, does BIND 9.14 has a patch to resolve this? Since we
have a multiple Cache server, we need to do this every time we encounter
another domain that has this same issue.

Thank you!

*Wil*



On Wed, Nov 6, 2019 at 3:50 PM Daniel Stirnimann <
daniel.stirnim...@switch.ch> wrote:

> federate.secure.barclays.com. is a CNAME pointing to
> federate-secure.glbaa.barclays.com
>
> The authoritative name servers for federate-secure.glbaa.barclays.com
> are broken:
>
> glbaa.barclays.com. 900 IN  NS  ns24.barclays.net.
> glbaa.barclays.com. 900 IN  NS  ns22.barclays.net.
> glbaa.barclays.com. 900 IN  NS  ns23.barclays.com.
> glbaa.barclays.com. 900 IN  NS  ns21.barclays.com
>
> They only seem to respond to A,  queries. Everything else times out.
> Queries with EDNS Cookies (RFC7873) timeout as well.
>
> You should be able to work around this by adding this to named.conf
>
> server 157.83.126.246 { send-cookie false; };
> server 157.83.102.246 { send-cookie false; };
> server 157.83.126.245 { send-cookie false; };
> server 157.83.102.245 { send-cookie false; };
>
> See also
>
> https://ftp.isc.org/isc/bind9/9.14.0/doc/arm/Bv9ARM.ch05.html#server_statement_grammar
>
> Daniel
>
>
> On 06.11.19 08:32, Wilfred Sarmiento via bind-users wrote:
> > Hi Bind Users,
> >
> > Anyone have a similar issue we are encountering with the subdomain of
> > Barclays.com specifically federate.secure.barclays.com
> > <http://federate.secure.barclays.com>
> > Our cache server could not resolve the said subdomain, but was able to
> > resolve their root domain barclays.com <http://barclays.com> and any
> > other known domains.
> > Debug just showed below little details of logs.
> > That subdomain was resolvable using Google DNS and other OpenDNS.
> >
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> > + (x.x.x.x)
> >
> > client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> > + (x.x.x.x)
> >
> > client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query failed (timed out) for
> > federate.secure.barclays.com/IN/A at query.c:6786
> >
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query: federate.secure.barclays.com IN A
> > + (x.x.x.x)
> >
> > client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852
> > (federate.secure.barclays.com): query failed (timed out) for
> > federate.secure.barclays.com/IN/A at query.c:6786
> >
> >
> > Thank you,
> > *Wil
> > *
> >
> >
> > This e-mail message (including attachments, if any) is intended for the
> > use of the individual or the entity to whom it is addressed and may
> > contain information that is privileged, proprietary, confidential and
> > exempt from disclosure. If you are not the intended recipient, you are
> > notified that any dissemination, distribution or copying of this
> > communication is strictly prohibited. If you have received this
> > communication in error, please notify the sender and delete this E-mail
> > message immediately.
> >
> >
> > ___
> > 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
> >
>

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


___
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

Query failed (timed out)

2019-11-05 Thread Wilfred Sarmiento via bind-users 
Hi Bind Users,

Anyone have a similar issue we are encountering with the subdomain of
Barclays.com specifically federate.secure.barclays.com
Our cache server could not resolve the said subdomain, but was able to
resolve their root domain barclays.com and any other known domains.
Debug just showed below little details of logs.
That subdomain was resolvable using Google DNS and other OpenDNS.

client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
query: federate.secure.barclays.com IN A + (x.x.x.x)

client @0x7f6a4a4cd070 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
query: federate.secure.barclays.com IN A + (x.x.x.x)

client @0x7f6a14a7b6a0 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
query failed (timed out) for federate.secure.barclays.com/IN/A at
query.c:6786

client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
query: federate.secure.barclays.com IN A + (x.x.x.x)

client @0x7f6a31216e30 xxx.xxx.xxx.xxx#63852 (federate.secure.barclays.com):
query failed (timed out) for federate.secure.barclays.com/IN/A at
query.c:6786

Thank you,

*Wil*

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


___
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

Query CNAME failed

2019-07-06 Thread Wilfred Sarmiento via bind-users 
Hi Mark,

Another findings i got in the server is that it intermittently cannot
resolve an external domain.
Any more idea to what i should be checking here?

Thank you,
Wil

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


___
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

Query CNAME failed

2019-07-03 Thread Wilfred Sarmiento via bind-users 
Hi Mark,

It also happen to all domain record with a CNAME on external domain. It
doesn't only happen in cebupacificair.com domain.
Also, i notice the issue happens after an hour of server reboot. From the
1st hour after reboot, the issue didn't happen. So i am thinking this might
be a session limit?

Wil


On Wed, Jul 3, 2019 at 4:19 PM Mark Andrews  wrote:

> Try just diagnosing why the lookup of book.cebupacair.cust.lldns.net
> and/or cebupacair-dd.lldns.net is failing which are the target in the
> CNAME chain.  You know the lookup of book.cebupacificair.com returns a
> CNAME record so the next step to a lookup of book.cebupacificair.com and
> book.cebupacificair.com/CNAME.
>
> ; <<>> DiG 9.15.1 <<>> book.cebupacair.cust.lldns.net
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5908
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: cbdd8bcfcc962e6a9e1b6a5e5d1c63554cdb8ed4c7c121da (good)
> ;; QUESTION SECTION:
> ;book.cebupacair.cust.lldns.net.IN  A
>
> ;; ANSWER SECTION:
> book.cebupacair.cust.lldns.net. 300 IN  CNAME   cebupacair-dd.lldns.net.
> cebupacair-dd.lldns.net. 60 IN  A   68.142.70.27
> cebupacair-dd.lldns.net. 60 IN  A   68.142.68.27
>
> Mark
>
> > On 3 Jul 2019, at 5:48 pm, Wilfred Sarmiento via bind-users <
> bind-users@lists.isc.org> wrote:
> >
> > Hi Bind Users,
> >
> > Currently drained my brain troubleshooting where could be the cause of
> my issue on one of our Authoritative DNS server.
> > When querying a CNAME directly to the server, where a CNAME is pointed
> to an external domain, results failed with timeout error and no server
> could be reached.
> >
> > ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> book.cebupacificair.com @
> dns1.globenet.com.ph
> > ;; global options: +cmd
> > ;; connection timed out; no servers could be reached
> >
> > Server logs produce 3 query log then show a query failed (timed out);
> >
> > client @0x7fd9ac0908d0 x.x.x.x#51579 (book.cebupacificair.com): query:
> book.cebupacificair.com IN A +E(0) (203.177.255.10)
> > client @0x7fd9a4484080 x.x.x.x#51579 (book.cebupacificair.com): query:
> book.cebupacificair.com IN A +E(0) (203.177.255.10)
> > client @0x7fd9a4481cb0 x.x.x.x#51579 (book.cebupacificair.com): query:
> book.cebupacificair.com IN A +E(0) (203.177.255.10)
> > client @0x7fd9ac0908d0 x.x.x.x#51579 (book.cebupacificair.com): query
> failed (timed out) for book.cebupacificair.com/IN/A at query.c:6786
> >
> > But when i send a query with +norecurse option, results is successful.
> >
> > dig +norecurse book.cebupacificair.com @dns1.globenet.com.ph
> >
> > ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> +norecurse
> book.cebupacificair.com @dns1.globenet.com.ph
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19755
> > ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;book.cebupacificair.com.   IN  A
> >
> > ;; ANSWER SECTION:
> > book.cebupacificair.com. 1200   IN  CNAME
> book.cebupacair.cust.lldns.net.
> >
> > ;; AUTHORITY SECTION:
> > lldns.net.  171335  IN  NS  ns1.lldns.net.
> > lldns.net.  171335  IN  NS  ns2.lldns.net.
> >
> > ;; ADDITIONAL SECTION:
> > ns1.lldns.net.  149880  IN  A   208.111.184.11
> > ns2.lldns.net.  93416   IN  A   208.111.184.12
> > ns1.lldns.net.  93416   IN  2607:f4e8:ac:1::11
> > ns2.lldns.net.  93416   IN  2607:f4e8:ac:1::12
> >
> > ;; Query time: 1 msec
> > ;; SERVER: 203.177.255.10#53(203.177.255.10)
> > ;; WHEN: Wed Jul 03 03:36:21 EDT 2019
> > ;; MSG SIZE  rcvd: 229
> >
> > This is the named.conf options;
> >
> > options {
> > directory "/var/namedb";
> > version "Query Not Allowed.";
> > allow-recursion { globenet; };
> > recursive-clients 100;
> > allow-query-cache { globenet; };
> > allow-query { any; };
> > tcp-clients 5000;
> >
> > blackhole { bogusnet; };
> >
> > pid-file "/var/local/bind/var/run/named.pid";
> > zone-statist

Query CNAME failed

2019-07-03 Thread Wilfred Sarmiento via bind-users 
Hi Bind Users,

Currently drained my brain troubleshooting where could be the cause of my
issue on one of our Authoritative DNS server.
When querying a CNAME directly to the server, where a CNAME is pointed to
an external domain, results failed with timeout error and no server could
be reached.



*; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> book.cebupacificair.com
 @dns1.globenet.com.ph
;; global options: +cmd;; connection timed
out; no servers could be reached*

Server logs produce 3 query log then show a query failed (timed out);




*client @0x7fd9ac0908d0 x.x.x.x#51579 (book.cebupacificair.com
): query: book.cebupacificair.com
 IN A +E(0) (203.177.255.10)client
@0x7fd9a4484080 x.x.x.x#51579 (book.cebupacificair.com
): query: book.cebupacificair.com
 IN A +E(0) (203.177.255.10)client
@0x7fd9a4481cb0 x.x.x.x#51579 (book.cebupacificair.com
): query: book.cebupacificair.com
 IN A +E(0) (203.177.255.10)*
*client @0x7fd9ac0908d0 x.x.x.x#51579 (book.cebupacificair.com
): query failed (timed out) for
book.cebupacificair.com/IN/A  at
query.c:6786*

But when i send a query with *+norecurse* option, results is successful.






























*dig +norecurse book.cebupacificair.com 
@dns1.globenet.com.ph ; <<>> DiG
9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> +norecurse book.cebupacificair.com
 @dns1.globenet.com.ph
;; global options: +cmd;; Got answer:;;
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19755;; flags: qr aa ra;
QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5;; OPT PSEUDOSECTION:;
EDNS: version: 0, flags:; udp: 4096;; QUESTION
SECTION:;book.cebupacificair.com .   IN
 A;; ANSWER SECTION:book.cebupacificair.com
. 1200   IN  CNAME
book.cebupacair.cust.lldns.net .;;
AUTHORITY SECTION:lldns.net .  171335  IN
 NS  ns1.lldns.net .lldns.net .
 171335  IN  NS  ns2.lldns.net
.;; ADDITIONAL SECTION:ns1.lldns.net
.  149880  IN  A
208.111.184.11ns2.lldns.net .  93416   IN
 A   208.111.184.12ns1.lldns.net .  93416
  IN  2607:f4e8:ac:1::11ns2.lldns.net .
   93416   IN  2607:f4e8:ac:1::12;; Query time: 1 msec;;
SERVER: 203.177.255.10#53(203.177.255.10);; WHEN: Wed Jul 03 03:36:21 EDT
2019;; MSG SIZE  rcvd: 229*

This is the named.conf options;















*options {directory "/var/namedb";version "Query Not
Allowed.";allow-recursion { globenet; };recursive-clients
100;allow-query-cache { globenet; };allow-query { any;
};tcp-clients 5000;blackhole { bogusnet; };pid-file
"/var/local/bind/var/run/named.pid";zone-statistics yes;
statistics-file "/var/namedb/named.stats";};*

Bind version is 9.14.2

The "globenet" group are the list of IPs we allowed for recursion. And this
issue happens only on the CNAME record with external domain.

Thank you in advance.

Regards,
*Wil Sarmiento*

-- 
This e-mail message (including attachments, if any) is intended for the use 
of the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that 
any dissemination, distribution or copying of this communication is 
strictly prohibited. If you have received this communication in error, 
please notify the sender and delete this E-mail message immediately.


___
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