Re: RPZ zone load failure ran out of space

[Jim Yang]

Hi Bob,


Thank you for the explanation. It makes sense to me now.


Best,

Jim


From: Bob Harold 
Sent: Wednesday, June 28, 2017 4:38 PM
To: Jim Yang
Cc: bind-users@lists.isc.org
Subject: Re: RPZ zone load failure ran out of space


On Wed, Jun 28, 2017 at 3:44 PM, Jim Yang 
> wrote:
Hi,

In the example below, when the length of bad.domain.com 
reaches 241 bytes, named-checkconf reports the following error:

“zone db.rpz.zone/IN: loading from master file db.rpz.zone failed: ran out of 
space
_default/db.rpz.zone/IN: ran out of space”

As per RFC1035, the DNS name maximum length is 255 bytes and each label length 
limit is 63 bytes.

I wonder what is the maximum length for bad.domain.com 
in the RPZ zone?

$ORIGIN rpz.example.com.
  $TTL 1H
  @   SOA LOCALHOST. 
named-mgr.example.com (1 1h 15m 30d 2h)
  NS  LOCALHOST.

  ; QNAME policy records.
  ; Note: There are no periods (.) after the (relativised) owner names.

bad.domain.com  A   10.0.0.1  ; redirect to 
walled garden
  2001:2::1

Thanks,
Jim

I just hit the same problem (we probably use the same block list source).
The actual DNS name is the combination of the ORIGIN and the entry:
bad.domain.com.rpz.example.com.
which exceeds 255 characters including the trailing dot, most likely.

--
Bob Harold


___
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: RPZ zone load failure ran out of space

[Bob Harold]

On Wed, Jun 28, 2017 at 3:44 PM, Jim Yang  wrote:

> Hi,
>
>
>
> In the example below, when the length of bad.domain.com reaches 241
> bytes, named-checkconf reports the following error:
>
>
>
> “zone db.rpz.zone/IN: loading from master file db.rpz.zone failed: ran out
> of space
>
> _default/db.rpz.zone/IN: ran out of space”
>
>
>
> As per RFC1035, the DNS name maximum length is 255 bytes and each label
> length limit is 63 bytes.
>
>
>
> I wonder what is the maximum length for bad.domain.com in the RPZ zone?
>
>
>
> $ORIGIN rpz.example.com.
>
>   $TTL 1H
>
>   @   SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d
> 2h)
>
>   NS  LOCALHOST.
>
>
>
>   ; QNAME policy records.
>
>   ; Note: There are no periods (.) after the (relativised) owner names.
>
>
>
> bad.domain.com  A   10.0.0.1  ; redirect to walled garden
>
>   2001:2::1
>
>
>
> Thanks,
>
> Jim
>

I just hit the same problem (we probably use the same block list source).
The actual DNS name is the combination of the ORIGIN and the entry:
bad.domain.com.rpz.example.com.
which exceeds 255 characters including the trailing dot, most likely.

-- 
Bob Harold
___
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

RPZ zone load failure ran out of space

[Jim Yang]

Hi,

In the example below, when the length of bad.domain.com reaches 241 bytes, 
named-checkconf reports the following error:

“zone db.rpz.zone/IN: loading from master file db.rpz.zone failed: ran out of 
space
_default/db.rpz.zone/IN: ran out of space”

As per RFC1035, the DNS name maximum length is 255 bytes and each label length 
limit is 63 bytes.

I wonder what is the maximum length for bad.domain.com in the RPZ zone?

$ORIGIN rpz.example.com.
  $TTL 1H
  @   SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
  NS  LOCALHOST.

  ; QNAME policy records.
  ; Note: There are no periods (.) after the (relativised) owner names.

bad.domain.com  A   10.0.0.1  ; redirect to walled garden
  2001:2::1

Thanks,
Jim
___
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: [E] Re: strange problem with query being dropped/ignored by the BIND process

[Marc Richter]

Hi Ben,

thanks for the answer.

Yeah, I think you are right. I see a lot of udpInOverflows on the system,
which suggest that the receive buffer is too small indeed.

Is there any kind of recommendation or best-practice advice what the
buffers should ideally be set to on Solaris ?
I did search the ISC Knowledge Base, but didn't find any useful advice.

Regards
arc

On 06/28/17 14:37, Ben Croswell wrote:
> Have you checked deeper at the OS level? I have seen on Linux DNS servers
> silent drops of queries on very busy servers that were exhausting UDP
> receive buffers.
> 
> On Jun 28, 2017 10:26 AM, "Marc Richter"  > wrote:
> 
> Hi,
> 
> we have a setup here consisting of a recursive DNS server and two
> monitoring servers. The monitoring servers sent a test query to the DNS
> server once every two minutes to check if it is answering properly.
> 
> We now have the problems that these test queries are timing out from time
> to time, (correctly) resulting in alarms in our monitoring system.
> 
> I have checked this now and noticed that each time we see that alarm, the
> query sent by the monitoring server is not being answered at all.
> To debug that I ran tcpdump on both the monitoring server and the 
> recursive
> DNS server. I see the query being sent out on the monitoring server and I
> also see the query being received on the DNS server, however there is no
> response sent to this query at all.
> Looking at the query log, which I enabled temporarily, the query is also
> not logged there so it looks like BIND is ignoring that query somewhere,
> although it is properly received by the IP stack of the server.
> 
> Do you have any suggestions how to debug this further, to hopefully find
> out where these queries are stuck/dropped/ignored, as I have run out of
> ideas ?
> 
> The environment is:
> BIND 9.9.9-P5 (Extended Support Version) 
> running on SunOS sun4v 5.11 11.3
> 
> 
> Thanks !
> Marc
> ___
> 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
> 
> 
> 
> 

-- 
Marc Richter
Engr III Cslt-Ntwk Eng

Sebrathweg 20
44149 Dortmund
Germany

O +49 231 972 1293
F +49 231 972 2587
E marc.rich...@de.verizon.com
___
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: strange problem with query being dropped/ignored by the BIND process

[Ben Croswell]

Have you checked deeper at the OS level? I have seen on Linux DNS servers
silent drops of queries on very busy servers that were exhausting UDP
receive buffers.

On Jun 28, 2017 10:26 AM, "Marc Richter" 
wrote:

Hi,

we have a setup here consisting of a recursive DNS server and two
monitoring servers. The monitoring servers sent a test query to the DNS
server once every two minutes to check if it is answering properly.

We now have the problems that these test queries are timing out from time
to time, (correctly) resulting in alarms in our monitoring system.

I have checked this now and noticed that each time we see that alarm, the
query sent by the monitoring server is not being answered at all.
To debug that I ran tcpdump on both the monitoring server and the recursive
DNS server. I see the query being sent out on the monitoring server and I
also see the query being received on the DNS server, however there is no
response sent to this query at all.
Looking at the query log, which I enabled temporarily, the query is also
not logged there so it looks like BIND is ignoring that query somewhere,
although it is properly received by the IP stack of the server.

Do you have any suggestions how to debug this further, to hopefully find
out where these queries are stuck/dropped/ignored, as I have run out of
ideas ?

The environment is:
BIND 9.9.9-P5 (Extended Support Version) 
running on SunOS sun4v 5.11 11.3


Thanks !
Marc
___
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
___
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

strange problem with query being dropped/ignored by the BIND process

[Marc Richter]

Hi,

we have a setup here consisting of a recursive DNS server and two
monitoring servers. The monitoring servers sent a test query to the DNS
server once every two minutes to check if it is answering properly.

We now have the problems that these test queries are timing out from time
to time, (correctly) resulting in alarms in our monitoring system.

I have checked this now and noticed that each time we see that alarm, the
query sent by the monitoring server is not being answered at all.
To debug that I ran tcpdump on both the monitoring server and the recursive
DNS server. I see the query being sent out on the monitoring server and I
also see the query being received on the DNS server, however there is no
response sent to this query at all.
Looking at the query log, which I enabled temporarily, the query is also
not logged there so it looks like BIND is ignoring that query somewhere,
although it is properly received by the IP stack of the server.

Do you have any suggestions how to debug this further, to hopefully find
out where these queries are stuck/dropped/ignored, as I have run out of ideas ?

The environment is:
BIND 9.9.9-P5 (Extended Support Version) 
running on SunOS sun4v 5.11 11.3


Thanks !
Marc
___
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: Problem w/ Forwarding Zone in Caching-Only Config

[Mark Andrews]

In message , Tony Finch 
writes:
> Mark Andrews  wrote:
> >
> > See https://tools.ietf.org/html/rfc6763 for details of how it is
> > designed to work.  Section 11 shows how to go from IP address and
> > netmask to the forward domain where the _dns-sd._udp subdomains
> > reside.
> >
> > lb._dns-sd._udp.0.43.168.136.in-addr.arpa PTR 
> 
> At Cambridge my colleagues have an experimental DNS-SD setup for printing
> from eduroam. Rather than the reverse DNS option, we're using the forward
> option where clients get the domain from DHCP, so I just needed to add a
> few records to the DNS and try not to worry too much about how competent
> the print server is at DNS. The forward option greatly simplifies wireless
> subnet allocation, and is conveniently v4/v6 agnostic.

The proceedure also works for IPv6 where for 99.99% of networks it
will be the reverse of the leading 64 bits.

e.g.
lb._dns-sd._udp.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA

but these are all alternatives.

> $ORIGIN private.cam.ac.uk
> b._dns-sd._udp.wirelessPTR pc-printer-discovery.wireless
> lb._dns-sd._udp.wireless PTR pc-printer-discovery.wireless
> pc-printer-discovery.wireless NS papercut-test.ds
> 
> Tony.
> -- 
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Viking, North Utsire: Northerly or northeasterly 4, occasionally 5 in Viking.
> Slight or moderate. Fair. Good.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Problem w/ Forwarding Zone in Caching-Only Config

[Tony Finch]

Mark Andrews  wrote:
>
> See https://tools.ietf.org/html/rfc6763 for details of how it is
> designed to work.  Section 11 shows how to go from IP address and
> netmask to the forward domain where the _dns-sd._udp subdomains
> reside.
>
> lb._dns-sd._udp.0.43.168.136.in-addr.arpa PTR 

At Cambridge my colleagues have an experimental DNS-SD setup for printing
from eduroam. Rather than the reverse DNS option, we're using the forward
option where clients get the domain from DHCP, so I just needed to add a
few records to the DNS and try not to worry too much about how competent
the print server is at DNS. The forward option greatly simplifies wireless
subnet allocation, and is conveniently v4/v6 agnostic.

$ORIGIN private.cam.ac.uk
b._dns-sd._udp.wireless  PTR pc-printer-discovery.wireless
lb._dns-sd._udp.wireless PTR pc-printer-discovery.wireless
pc-printer-discovery.wireless NS papercut-test.ds

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire: Northerly or northeasterly 4, occasionally 5 in Viking.
Slight or moderate. Fair. Good.
___
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