Question about Google domain with recursive resolver

[J Doe]

Hello,

I have a basic recursive resolver configuration with Bind 9.18.19 that 
acts as the resolver for some VPN roadwarrior clients (a mix of Apple 
iOS and macOS clients).


Periodically I will see the following in my logs:

02-Nov-2023 15:06:27.658 resolver: info: loop detected resolving 
'ns1.zdns.google/A'


As this is logged at "info" level, I presume it doesn't do any harm, but 
has anyone run into this with this particular Google domain ?  I have 
seen it over a number of weeks.


Thanks,

- J
--
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

Question about URL being logged by resolver

[J Doe]

Hello,

On a Bind 9.18.19 server configured as a recursive resolver, I sometimes 
see URL's being noted in the log files.


One such example is:

02-Nov-2023 23:32:19.435 lame-servers: info: success resolving 
'https://app-measurement.com/sdk-exp/A' after disabling qname 
minimization due to 'ncache nxdomain'


This seems unusual to me because Bind usually notes the domain name it 
is attempting to resolve, not an URL.  In this particular case, I would 
expect to see a notation about "app-measurement.com" and not "http://etc";.


What is the significance of logging the URL and why does this happen in 
only some cases ?


Thanks,

- J
--
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

Question about resolver

[J Doe]

Hello,

I run BIND 9.18.26 as a recursive, validating resolver.  In my logs, I
noticed the following:

22-Apr-2024 19:25:59.614 lame-servers: info: chase DS servers
resolving '180.96.34.in-addr.arpa/DS/IN': 216.239.34.102#53

What does "chase DS servers" mean ?

Thanks,

- J
--
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: Question about resolver

[J Doe]

On 2024-04-25 08:55, Josh Kuo wrote:


DS = Delegation Signer, it is the record type that a signed child upload
to the parent zone. It's difficult to say for sure without more
information such as which domain name you are trying to resolve, but
looks like it is probably due to a mis-matching DS record between the
child and the parent (security lameness).

You can use tools such as
https://dnssec-analyzer.verisignlabs.com/online
 to help you analyze
further. If you need to refresh your knowledge on how DNSSEC works, see
the ISC DNSSEC Guide:
https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html


-Josh


Hi Josh,

Thank you for your prompt reply!

In this particular case, isn't the resolver attempting to do a reverse
lookup of the IP address that's listed ?

Secondly, I'm still not entirely sure what the phrasing "chase DS
servers" means.  I am aware of the DS RR type.

As a side-note:  I believe the "lame-servers" here is a function of me
configuring QNAME minimization to "relaxed".

Thanks,

- J
--
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: Question about resolver

[J Doe]

On 2024-04-26 16:28, Mark Andrews wrote:


DS records live in the parent zone and the RFC 1034 rules for serving zone 
break down when a grandparent zone and child zone are served by the same 
server.  This is corrected be the client by looking for intermediate NS records 
to find the hidden delegations then resuming the DS lookup.

Named was looking up theses NS records I.e. chasing the DS servers.   This can 
result in named finding delegation errors.  QNAME minimisation also exposes 
these errors as it also does NS queries.  Garbage in breakage out.


Hi Mark,

Ah, ok, I believe I've got it now - thanks for you explanation!

- J
--
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: Question about resolver

[J Doe]

On 2024-04-26 16:45, Josh Kuo wrote:


In this particular case, isn't the resolver attempting to do a reverse
lookup of the IP address that's listed ?


You are right, I missed that this is a reverse-mapping zone. In that
case, run DNSSEC analyzer on the domain "180.96.34.in-addr.arpa" and
you'll see the problem. Reverse-mapping zones work the same as
forward-mapping zones, they also need to be delegated properly.

If you prefer a more visual output, try DNSViz:
https://dnsviz.net/d/180.96.34.in-addr.arpa/dnssec/



Hi Josh,

Ok, sounds good!

- J

--
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

Truncated TCP ?

[J Doe]

Hello,

I run BIND 9.18.26 as a recursive, validating resolver.  In my logs, I
noticed the following:

01-May-2024 00:52:49.689 lame-servers: info: truncated TCP response
resolving 'www.ipfire.org/A/IN': 74.113.60.134#53

I am aware that there are issues with DNS UDP traffic being truncated
and/or rejected via firewalls or middle-boxes that enforce limits on
expected packet size (I believe one of the goals of a recent Flag Day
was to address these configs), but what would lead to truncated TCP
traffic in the context of DNS ?

Thanks,

- J
--
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: Truncated TCP ?

[J Doe]

On 2024-05-05 20:47, Mark Andrews wrote:





On 6 May 2024, at 07:38, J Doe  wrote:

Hello,

I run BIND 9.18.26 as a recursive, validating resolver.  In my logs, I
noticed the following:

01-May-2024 00:52:49.689 lame-servers: info: truncated TCP response
resolving 'www.ipfire.org/A/IN': 74.113.60.134#53

I am aware that there are issues with DNS UDP traffic being truncated
and/or rejected via firewalls or middle-boxes that enforce limits on
expected packet size (I believe one of the goals of a recent Flag Day
was to address these configs), but what would lead to truncated TCP
traffic in the context of DNS ?


Usually it is a software bug in the server where it doesn’t support 65535 byte
responses or incorrectly applies UDP limits to TCP.  Very occasionally the
response actually won’t fit in 65535 bytes.

Whatever it was I’m not seeing it now.

Mark


Thanks,

- J


Hi Mark,

When you say "server" do you mean my server (which implies that there is
a TCP/IP stack issue on my end), or the remote server (in this case the
authoritative DNS Server for: www.ipfire.org) ?

Thanks,

- J
--
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

CIDR notation for RPZ rpz-ip ?

[J Doe]

Hello,

When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used
or must they be either: /8, /16, /24, /32 for IPv4 ?

For example, if I want to block records with an A address of
192.168.10.1, I know I can write:

32.1.10.168.192.rpz-ipINCNAME .

... and records like A, MX, etc. that have an A value of: 192.168.10.1
will receive a NXDOMAIN response.

But am I able to block any CIDR ?  For instance, if I wanted to block
records like A, MX, etc. that have A values in: 192.168.10.1/22 can I
use the following:

22.1.10.168.192.rpz-ipINCNAME .


Thanks,

- J
--
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

Missing cookie

[J Doe]

Hi list,

I run a validating recursive resolver with BIND 9.18.27.  Over the
course of many days, I have noted the following warning about a missing
cookie from a particular server:

09-May-2024 20:09:22.277 resolver: info: missing expected cookie
from 192.5.5.241#53

This server runs in the cloud with excellent connectivity, I don't do
anything special with my firewall and I do not run any software that
would mutate the DNS data over port 53.

What could be causing the cookie to not be received from this particular
server over a number of days ?

Thanks,

- J

--
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: CIDR notation for RPZ rpz-ip ?

[J Doe]

On 2024-05-17 19:37, Nick Tait via bind-users wrote:


On 18/05/2024 09:11, J Doe wrote:

Hello,

When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used
or must they be either: /8, /16, /24, /32 for IPv4 ?

For example, if I want to block records with an A address of
192.168.10.1, I know I can write:

    32.1.10.168.192.rpz-ip    IN    CNAME .

... and records like A, MX, etc. that have an A value of: 192.168.10.1
will receive a NXDOMAIN response.

But am I able to block any CIDR ?  For instance, if I wanted to block
records like A, MX, etc. that have A values in: 192.168.10.1/22 can I
use the following:

    22.1.10.168.192.rpz-ip    IN    CNAME .


Thanks,

- J


Hi J.

Yes you can specify a CIDR network length that isn't on an 8-bit boundary.

In your example the /22 network address for 192.168.10.1 is actually
192.168.8.0, so you'd specify:

22.0.8.168.192.rpz-ip IN CNAME .

Nick.


Hi Nick,

Thanks for your reply and thanks for catching my network error!

- J

--
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

Difference between query hung and timeout

[J Doe]

Hi list,

I run a BIND 9.18.27 resolver on a small mail server.

Sometimes in the logs I will see entries similar to the following:

04-Jul-2024 12:20:48.048 query-errors: info: client @0x3777f6412b0
127.0.0.1#48123 (bras-base-toroon0964w-
grc-41-142-198-14-9.dsl.bell.ca): query failed (timed out) for
bras-base-toroon0964w-grc-41-142-198-14-9.dsl.bell.ca/IN/A at
query.c:7843

04-Jul-2024 20:07:35.308 resolver: info: shut down hung fetch
while resolving '164.212.87.77.in-addr.arpa/PTR'

My question is: what is the difference between a query that times out
versus a query that hangs ?

In both cases, I would think these queries are hitting a time limit and
are stopped by BIND, but  the fact that there are two different log
entries makes me wonder if there's more to this.

Thanks,

- J
--
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

Question about "too many records"

[J Doe]

Hi,

I run my own validating recursive resolver with BIND 9.18.28.

In the resolver logs I noticed:


01-Aug-2024 10:30:22.294 query-errors: info: client @0xec879280280
127.0.0.1#14435 (bf10x.hubspotemail.net): query failed (too many
records) for bf10x.hubspotemail.net/IN/A at query.c:7842


The client in this case was my mail server software.  What does "query
failed (too many records) ..." mean ?

Is this BIND saying that the client (the mail server software),
requested too many records or that the result of the query yielded too
many records or something else ?

Thanks,

- J
--
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: Question about "too many records"

[J Doe]

On 2024-08-02 04:30, Petr Špaček wrote:


On 02. 08. 24 0:52, Tim Daneliuk wrote:

On 8/1/24 17:14, John Thurston wrote:

After reading the CVE description, it isn't clear to me how the
degraded performance is manifest.

If 300 A-records exist for the name 'foo', do we expect:

 1. queries for A-records for 'foo' will be slower than expected

Query like that will consume more CPU time - and thus make everything
else also slower.

The limit is controlled by max-records-per-type configuration statement.
See https://bind9.readthedocs.io/en/v9.18.28/reference.html#namedconf-
statement-max-records-per-type

The more you allow the slower it will become.


 2. all queries for 'foo' will be slower than expected

This can happen too, when 'foo' has large number of RR _types_ on it,
like TYPE1000, TYPE1001, ..., TYPE1100.

Mitigation/limit for this is controlled by max-types-per-name
configuration statement. See https://bind9.readthedocs.io/en/v9.18.28/
reference.html#namedconf-statement-max-types-per-name

The more you allow the slower it will become.


 3. every query to the server will be slower than expected

... while query for 'foo' is being processed.


 4. something else


This is potential attack vector for resolvers: An attacker can always
create large RRset on authoritative server under attacker's control and
then query resolver for the humonguous RRset repeatedly - slowing down
everything.


I also have a basic confusion about this general topic.

I got bit by this when I updated to .28 because I had some fairly
large round robin pools within our non-routable network.

In my (admittedly brief) research, I was under the impression that
the limitation was total number of records per type to reduce
the risk of cache poisoning, not for performance reasons.

If that's so, there needs to be a way to disable it by policy/option
for the local horizon in a split horizon implementation where one
might need a lot of records and the risk of cache poisoning is
essentially zero.

If someone would please help deconfuse me, I would be deeply
appreciative.


This is not related to cache poisoning, see above.


Hi list,

My apologies for not realizing that this was related to the recent BIND
software update and that it had already been discussed.

Thank you for the answers.  I ended up testing this again on my mail
server with its' recursive resolver and can confirm I still get the "too
many records" in my logs, whereas if I query via dig @8.8.8.8 (Google),
for A records, I get numerous A record results ... looks like a little
over 100.

Next, I adjusted the: max-records-per-type parameter in: named.conf, as
Petr had mentioned.  Bumping it from the default of 100 to 120 and
repeating the test allows my resolver to return all the A records.

Thank you for the warning of potential DoS ... I am thinking that a
small increase on a server that doesn't get/generate a huge of e-mail
traffic should be ok.

- J



--
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: Trying again on SERVFAIL

[J Doe]

On 2021-02-10 3:05 a.m., Alessandro Vesely wrote:

Hi Havard,







That's what I've been doing.  For an incoming message, a temporary 
failure means replying a 4xx code.  The sender keeps the message in its 
queue, and eventually gives up.  Once upon a time, MTAs used to retry 
sending for five days.  Nowadays, several servers don't let queued 
messages grow older than one day.


In the most severe case, a failed DKIM signature might entail a reject.  
So the best course of action seems to be to reserve temporary failures 
to this case.


Still, being able to differentiate a local network congestion from a 
remote bad configuration would help.



Best
Ale


Hi Ale and list,

This isn't an answer to your original question, but I was curious about 
something you mentioned near the end of your message, where you wrote: 
"Once upon a time . . . Nowadays, several servers don't let queued 
messages grow older than one day".


Out of curiosity, what servers have you encountered that no longer use 
the five day cutoff ?


Thanks,

- J
___
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

Question about missing bind.keys

[J Doe]

Hello,

I have a question about the bind.keys file and what happens when it is 
not available.


According to the ARM:

dnssec-validation  This option enables DNSSEC validation in named.
. . .

(To prevent problems if bind.keys is not found, the current trust
 anchor is also compiled in named. Relying on this is not
 recommended, however, as it requires named to be recompiled with a
 new key when the root key expires.)

I note the part towards the bottom where it says _not_ to rely on the 
compiled in option when bind.keys is not found.


With the packaged version of BIND that I am using (BIND 9.16.27), no 
bind.keys file was provided.  I then enabled DNSSEC validation by 
adding: dnssec-validation auto in my named.conf file and restarted BIND.


I now see I have managed-keys.bind file in my BIND directory.  To find 
out more about that I went to [1] which states:


For Current Releases (BIND 9.11 and higher)
. . .
Once named is managing the keys, the current keys will be
in managed-keys.bind or *.mkeys, if you use views.

In my case, I have BIND configured as a recursive resolver.  I have an 
ACL section and an Options section but no views . . . but I still get 
managed-keys.bind.


My question is:

** If I don't have bind.keys in my BIND directory but have: 
dnssec-validation auto in my named.conf, is BIND automatically getting 
the trust anchor and storing it in managed-keys.bind so that when my 
recursive resolver does a lookup and performs DNSSEC validation, 
validation works ?  Or do I still need to download bind.keys from [1] ?



Thanks for your help,

- J


Sources:

[1] https://www.isc.org/bind-keys/
--
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: Question about missing bind.keys

[J Doe]

On 2022-03-30 02:23, Evan Hunt wrote:


On Wed, Mar 30, 2022 at 12:16:05AM -0400, J Doe wrote:

I have a question about the bind.keys file and what happens when it is
not available.

[...]

** If I don't have bind.keys in my BIND directory but have:
dnssec-validation auto in my named.conf, is BIND automatically getting
the trust anchor and storing it in managed-keys.bind so that when my
recursive resolver does a lookup and performs DNSSEC validation,
validation works ?  Or do I still need to download bind.keys from [1] ?


There's a copy of bind.keys that's compiled directly in named. If
the file isn't there, named will just use its own internal copy.

The first time named starts up with 'dnssec-validation' set to 'auto',
it fetches the current root key, validates it against its local
copy (either from bind.keys or from its own built-in copy), and then
keeps the key up to date according to the RFC 5011 protocol from
then on.

The recommendation to use bind.keys and not rely on the built-in
version was based on some assumptions that are no longer true. First,
`dnssec-validation auto` is now the default, so unless you disabled it on
purpose, you've been validating and keeping the root key up to date since
the first time you ran your server.  Second, back in those days it was
harder to get hold of regularly-updated packages for BIND, and scads
of people were running outdated code.

We were concerned that someone would be running an old version of named,
the root key would change, and *then* they'd decide to turn validation on
for the first time, and it wouldn't work. To smooth that out a bit, we
added the bind.keys file to the release tarball, and when giving tutorials
about turning on DNSSEC validation, we included a note that you should
always check whether bind.keys needed to be updated.

In today's world, I don't think it's inmportant anymore.



Hi Evan,

Apologies for my late reply.  Thank you so much for the detailed 
explanation of: dnssec-validation auto and what happens when: bind.keys 
doesn't exist.


With this setting in place in my: named.conf I then restarted BIND, gave 
it a second to pull the trust information and then used: delv to test 
verification.


The first test for unverified/unsigned was:

$ delv google.com
; unsigned answer
. . .

... and the second test for verified/signed was:

$ delv ietf.org
; fully validated
. . .

... which wouldn't have worked if: dnssec-validation auto failed in 
getting the same information as: bind.keys


- J
--
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

BIND 9.18.2 break-dnssec question

[J Doe]

Hi,

I am configuring an RPZ for a validating resolver.  I read in the BIND 
9.18.2 ARM that there is a boolean option for RPZ zones called: 
break-dnssec.


The ARM states:

...In that case, RPZ actions are applied regardless of DNSSEC.
The name of the clause option reflects the fact that results
rewritten by RPZ actions cannot verify.

In my particular scenario, I want to use RPZ to give NXDOMAIN results 
for certain domain names that I don't want accessible.  So for normal 
queries without DNSSEC validation requested and for queries with DNSSEC 
validation requested for a domain name I am _not_ blocking, I want the 
lookups to work (ie: don't validate when validation not requested, 
validate when validation requested).


When a client attempts to lookup a domain name that _is_ blocked by RPZ, 
I want the domain name blocked ... whether or not they requested DNSSEC 
validation.


Am I correct that: break-dnssec yes comes into play only if a client 
attempts to resolve a DNSSEC secured domain name I _am_ blocking in RPZ ?


So for instance...

1. Client requests no validation for example.com which is not in RPZ and 
gets normal result.


2. Client requests validation for example.com which is not in RPZ and 
gets validated result.


3. Client requests no validation for evil.com which is in RPZ and gets 
NXDOMAIN result.


4. Client requests validation for evil.com which is in RPZ and gets 
NXDOMAIN result with broken DNSSEC validation due to rewrite.


This would mean that: break-dnssec yes:

...only breaks DNSSEC validation for evil.com because it is re-written
...does NOT break DNSSEC validation for sites _NOT_ in RPZ that use 
DNSSEC (ie: ietf.org).


Is that correct ?

Thanks,

- J
--
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: BIND 9.18.2 break-dnssec question

[J Doe]

On 2022-04-29 01:18, Mark Andrews wrote:


break-dnssec is about if the client could detect the re-write or not using 
DNSSEC.  If the client has DO=1 in the request and the normal response is 
signed then rewrites can be detected. If break-dnssec is ’no’ the rewrite will 
be prevented.  If break-dnssec is ‘yes’ then the rewrite will occur.


the world <-> recursive server rpz w/ break-dnssec no <-> recursive server rpz 
w/ break-dnssec no or yes;
 ||
   non dnssec clientnon dnssec 
client

You don’t want the second recursive server to spend all its time re-asking 
queries that will fail validation


On 29 Apr 2022, at 11:24, J Doe  wrote:

Hi,

I am configuring an RPZ for a validating resolver.  I read in the BIND 9.18.2 
ARM that there is a boolean option for RPZ zones called: break-dnssec.

The ARM states:

...In that case, RPZ actions are applied regardless of DNSSEC.
The name of the clause option reflects the fact that results
rewritten by RPZ actions cannot verify.

In my particular scenario, I want to use RPZ to give NXDOMAIN results for 
certain domain names that I don't want accessible.  So for normal queries 
without DNSSEC validation requested and for queries with DNSSEC validation 
requested for a domain name I am _not_ blocking, I want the lookups to work 
(ie: don't validate when validation not requested, validate when validation 
requested).

When a client attempts to lookup a domain name that _is_ blocked by RPZ, I want 
the domain name blocked ... whether or not they requested DNSSEC validation.

Am I correct that: break-dnssec yes comes into play only if a client attempts 
to resolve a DNSSEC secured domain name I _am_ blocking in RPZ ?

So for instance...

1. Client requests no validation for example.com which is not in RPZ and gets 
normal result.

2. Client requests validation for example.com which is not in RPZ and gets 
validated result.

3. Client requests no validation for evil.com which is in RPZ and gets NXDOMAIN 
result.

4. Client requests validation for evil.com which is in RPZ and gets NXDOMAIN 
result with broken DNSSEC validation due to rewrite.

This would mean that: break-dnssec yes:

...only breaks DNSSEC validation for evil.com because it is re-written
...does NOT break DNSSEC validation for sites _NOT_ in RPZ that use DNSSEC (ie: 
ietf.org).

Is that correct ?

Thanks,

- J


Hi Mark,

Thanks for your reply!  I think I might have done a poor job asking my 
questions, which may have introduced some confusion - apologies.  My 
brain is still chewing on this!


In this particular scenario, I have one validating resolver.  The 
diagram would be:


Client (PC, mail server, etc.) -> My resolver -> The world

What I was wondering is if I configure my validating resolver to use: 
break-dnssec yes, does that mean that DNSSEC validation is broken for 
_ALL_ queries ?


I am thinking that this applies only when a client computer queries my 
validating resolver and wants to know if DNSSEC is valid on a query that 
my resolver has changed via RPZ.  Because RPZ modified the data it can 
no longer validate.


So the client queries my resolver for DNSSEC validity for a server that 
is _NOT_ covered by my RPZ policy ... validation should _NOT_ break in 
that circumstance, right ?


Thanks,

- J
--
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

Question regarding newsyslog.conf and Bind logs

[J Doe]

Hello,

I was wondering if anyone could provide feedback on whether the 
following: newsyslog.conf file is correct to allow for daily log 
rotation for my Bind 9.16.30 logs ?


My currently logging settings in: named.conf are:

...
logging {
channel chn_file_queries {
buffered no;
file "/var/queries.log"
versions 2 size 1g suffix increment;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
...
};
...

newsyslog.conf examples tend to make use of: pkill but I note in the 
Bind ARM and man page that signals are deprecated in favor of: rndc.


I am *thinking* the following should work for newsyslog.conf

/var/named/var/queries.log6407 *$D0  Z 
"/usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true"


So settings:

Log path: My Bind is running in chroot
File mode:0640
Log count:7 (1 per day)
Size limit:   none
Frequency:$D0 (daily)
Flags:z to compress
Binary:   rndc (instead of pkill)

Is this correct ?

Thank you,

- J
--
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: Question regarding newsyslog.conf and Bind logs

[J Doe]

On 2022-08-25 03:05, Greg Choules wrote:


Hello J
What is it you're actually trying to achieve here?

Cheers, Greg


Hi Greg,

I'm looking to have my: queries.log (which logs all the queries my Bind 
9.16.30 recursive resolver resolves), rotated at the end of the day and 
I'd like to keep 7 days worth of those logs.


I didn't see anywhere in the log rotation options for: named.conf that 
mentioned rotation based on *time*.  I saw I can configure rotations 
based on the size of the file, but I'd like rotation to happen once 
every 24 hours.


With that in mind, I believe I could change the logging stanza from:

file "/var/queries.log"
versions 2 size 1G suffix increment;

to (syntax might be incorrect):

file "/var/queries.log"
size 1G;

I still want any daily log *before* it's being rotated to be a maximum 
size of 1 GB.


I believe my: newsyslog.conf line to rotate the logs daily is correct, 
except I wasn't entirely sure what the: rndc equivalent of sending 
SIGHUP to Bind was, as the ARM and man note that sending signals to 
control Bind is deprecated.


Thanks,

- J
--
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: Question regarding newsyslog.conf and Bind logs

[J Doe]

On 2022-08-25 04:52, Anand Buddhdev wrote:


On 25/08/2022 05:23, J Doe wrote:

Hello J Doe,

I was wondering if anyone could provide feedback on whether the 
following: newsyslog.conf file is correct to allow for daily log 
rotation for my Bind 9.16.30 logs ?


My currently logging settings in: named.conf are:

 ...
 logging {
 channel chn_file_queries {
 buffered no;
 file "/var/queries.log"
 versions 2 size 1g suffix increment;


This configuration makes BIND rotate the file by itself, when it grows 
bigger than 1 GB. You do NOT need any external tool like newsyslog to do 
log file rotation.


Regards,
Anand


Hi Anand,

Yes, I am aware that the logging stanza I listed for the query log will 
do the rotation when the log reaches 1 GB and then it will rotate it and 
store two logs in total.


What I would like to introduce is rotation based on time.  So after 24 
hours, newsyslog would compress and rotate the logs and keep them for 7 
days before removing the oldest.  That way I always have a week's worth 
of query data in separate logs by day.


Was my newsyslog.conf file correct for that ?

Thanks,

- J

--
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: Question regarding newsyslog.conf and Bind logs

[J Doe]

On 2022-08-25 16:46, Richard T.A. Neal wrote:


Hi J,

I'm coming a little late to the party on this one and I think you might 
struggle to do rotation based on both date/time *and* file size, but I use 
logrotate to rotate all of my BIND logs daily, keeping 31 days of logs. And 
you'll see that one of the last things that logrotate does is to call [rndc 
reconfig] which causes BIND to generate fresh log files in place of the rotated 
ones.

My BIND logging itself is setup based largely on the configuration described 
here:
https://kb.isc.org/docs/aa-01526

My logrotate.conf file then looks like this the following, which itself is 
based on this:
https://ixnfo.com/en/logrotate-bind9.html

#-
# RTAN BIND 9 daily log rotation
#
# Note that the log file won't rotate until at least one day AFTER you set this 
for the first time.
# Eg if you create this file on a Wednesday then they won't rotate for the 
first time until THURSDAY night:
# https://serverfault.com/questions/375004/logrotate-not-rotating-the-logs
#-

/var/log/named/*.log
{
   olddir /var/log/named/archived
   compress
   create 0644 bind bind
   daily
   dateext
   missingok
   notifempty
   rotate 31
   sharedscripts
   postrotate
 /usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true
   endscript
}
#-

Best,
Richard.


Hi Richard,

Thank you for your reply.  I am not attempting to configure the server 
so that rotation is based on size *and* time.  The size configuration in 
the logging stanza was more to put an upper limit on a log *before* it 
is rotated.  I could drop the parts that mention 2 versions and 
incrementing the filename and just keep: size 1G.


Let's say it's an extremely busy day and my Bind recursive resolver logs 
are getting really big.  I want the maximum size a day's logs can be 
*before* they are compressed to be 1G.  I am aware that if the server is 
still under heavy load that queries past that point will not be logged.


Then, at the end of the day, newsyslog compresses the logs and rotates 
them so that I keep 7 days worth of compressed logs.


The logrotate your example uses looks good, but I'm on a very minimal 
OpenBSD 7.1 host.  I could add the logrotate package, but newsyslog is 
in the base system and I already use it for doing the same kind of log 
rotation for my firewall logs, so I was hoping to stick to newsyslog.


The postrotate directive in the logrotate example you sent me was what I 
was basing my newsyslog config on, as it uses rndc and not pkill SIGHUP.


I am assuming it would work with newsyslog, or am I incorrect about that ?

Thanks again,

- J
--
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: Question regarding newsyslog.conf and Bind logs

[J Doe]

On 2022-08-25 18:04, Greg Choules wrote:

Hi again J.
If I understand correctly, you want to enable querylog on a busy 
recursive server permanently, rotate the files once a day and don't care 
if you lose some logs because the number of queries on a busy day 
generates more data than the specified log file is allowed to contain.


My question has to be, why?

Firstly, querylog is not an efficient way to record information about 
what your clients are doing, dnstap is far more efficient if you want a 
record of some or all information about queries and/or their responses. 
If using files to retain this information, the rotation choices are the 
same as for channels. If your server is only handling a few 10s or 100s 
QPS, querylog will do. But if it's handling 1000s times more than that 
you will cause it unnecessary extra stress and dnstap is your friend.


Secondly, if you insist on using querylog (actually, this also applies 
to dnstap), why not just leave named to rotate the files based on size 
and number, allowing for the set of files to be easily large enough to 
contain (say) a week's worth of data. Then you could run a cron job to 
grep today's logs and do what you want with them. You don't have to 
worry about other processes sending commands to named to cause something 
to happen, it just gets on with it.


/soapbox.


Hi Greg,

Yes, that's correct.  The size limit for the busy day is actually much 
larger than I think it would ever get.  I want a size limit to ensure 
that the query logs are not eating up too much disk space.  The size 
limit of a days' log will never get that high, but if it does, the disk 
is not filled up.  In that case, I understand logging for that day may 
be incomplete because Bind would stop logging if I it did get to 1 G, 
but for this server and the purpose it serves, it's never going to reach 
1 G.


I like to have an upper bound on logs to prevent disk from being filled up.

I am familiar with dnstap but am looking for a more simple solution at 
this time.  I agree it is probably the most correct tool for most jobs, 
but in this case text logs for queries are fine.


I could also do as you suggest with cron and grep, but I'm not concerned 
with sending commands via a separate process (rndc) as that is the 
current method of sending commands to Bind.  The big goal is to have 
compressed logs for 24 hours of queries, holding onto that data for a 
week.  I think that's achievable by newsyslog.


It would be great to know if:

/usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true

...is the correct trigger for named to open a new log.  Can anyone 
provide feedback on that ?


Thanks,

- J
--
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

RPZ for reverse lookups ?

[J Doe]

Hello,

I have a basic question regarding RPZ on Bind 9.11.x.

Is it possible to re-write a response on a reverse lookup ?  For instance, if I 
considered example.com a “bad domain”, can I write a RPZ policy so that a 
reverse lookup of IP’s that map to example.com fails or is blocked ?

I know I can do this with a forward lookup to generate NXDOMAIN:

; Forward resolution of: example.com and subdomains generates: NXDOMAIN

example.comIN CNAME .
*.example.com  IN CNAME .

…but can this also be done on reverse lookups ?

Thanks,

- J___
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 for reverse lookups ?

[J Doe]

Hi Noel and Fred,

Thank you for your replies.  I probably should have provided a bit of context 
about my situation.

I manage a small e-mail server for a client.  While setting up support for the 
SpamHaus DNSBL, I read that SpamHaus prefers that people use a non-public (ie: 
not 8.8.8.8 / large cloud host DNS server) recursive resolver.  I configured 
Bind 9.11.x to be a recursive resolver and got SpamHaus working with my MTA.  I 
then learned about RPZ.

I configured RPZ to block forward lookup of known bad domains - for instance, 
malware C2 servers and so forth, with the idea being that if the e-mail server 
was infected with malware it would fail forward resolution.  I then wondered if 
I could configure RPZ to “work in reverse” - that is, to specify a DNS name 
that results after reverse lookup should result in functionality similar to 
NXDOMAIN.

The idea behind this was that if a had a domain name or a TLD that I didn’t 
want to receive connections from, when the server performed the reverse lookup 
if it resulted in a domain with that TLD it would break, which would then cause 
my MTA to refuse delivery.  Currently, my MTA will happily allow a connection 
if the reverse resolution to any name works.

The reason I wanted this on the DNS name was that I then do not have to know 
all the IP addresses associated with that domain.  So, if I receive a 
connection from: 1.2.3.4 when the MTA does a reverse lookup and it matches 
“example.org <http://example.org/>” the DNS server doesn’t complete the name 
lookup.  In this case I am then specifying that anything that resolves to 
“example.org <http://example.org/>” should fail.  With the example you provided 
with a PTR record, I would still have to know the IP addresses owned by a 
particular domain, which may change over time.

I’ve been able to approach this in a different way.  Instead of having 
everything break at the DNS level, I’ve configured a right-hand side block list 
(RHSBL), with the MTA.  Now, when a reverse resolution is done if that domain 
name or TLD is found in the RHSBL, the connection is blocked.  I have that 
applied to connections to the server as well as the envelope from address, so 
if someone connects from: banned.example.com <http://banned.example.com/> OR 
states the e-mail is from: some...@banned.example.com 
<mailto:some...@banned.example.com>, the e-mail is rejected.

I think the major difficulty I was running into was trying to have DNS RPZ do 
everything.

Thank you for the pointer to the RPZ mailing list - I will be joining that 
shortly

Regards,

- J



> On Aug 25, 2019, at 12:54 PM, m3047  wrote:
> 
> Clarification on what DNS is...
> 
> On Sun, 25 Aug 2019, m3047 wrote:
>> On Sat, 24 Aug 2019, J Doe wrote:
>>> [...] Is it possible to re-write a response on a reverse lookup ?  For
>>> instance, if I considered example.com a “bad domain”, can I write a RPZ
>>> policy so that a reverse lookup of IP’s that map to example.com fails or
>   
>>> is blocked ?
>>> [...]
>> proposed actions local in scope? Do you run a local passive DNS oracle?)
> 
> Strictly speaking, in DNS-speak the "reverse lookup of an IP..." is a PTR 
> lookup. The "reverse lookup of an IP mapping to example.com" is doing a PTR 
> lookup and matching it against example.com. I could be wrong generally, but 
> at least none of the RPZ features which I use generate additional DNS 
> traffic; an RPZ implementation which did would exceed my personal threshold 
> of least surprise.
> 
> You might consider taking discussion of this to the RPZ interest list or 
> searching the archives: http://lists.redbarn.org/mailman/listinfo/dnsfirewalls
> 
> --
> 
> Fred Morris

___
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: Determining case of REFUSED queries

[J Doe]

On 2024-09-19 19:17, Mark Andrews wrote:

I think the reason for the REFUSED is pretty obvious

% dig +norec google._domainkey.socialinnovation.ca @173.245.59.231 txt

; <<>> DiG 9.21.0-dev <<>> +norec google._domainkey.socialinnovation.ca 
@173.245.59.231 txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10815
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 20 (Not Authoritative)
;; QUESTION SECTION:
;google._domainkey.socialinnovation.ca. IN TXT

;; Query time: 14 msec
;; SERVER: 173.245.59.231#53(173.245.59.231) (UDP)
;; WHEN: Fri Sep 20 09:03:48 AEST 2024
;; MSG SIZE  rcvd: 72

%

Now you just need to work out why you where asking 173.245.59.231
rather than the actual nameservers for socialinnovation.ca.

socialinnovation.ca. 86400 IN NS dns.rebel.ca.
socialinnovation.ca. 86400 IN NS dns2.rebel.ca.
dns2.rebel.ca. 86400 IN A 52.10.144.165
dns.rebel.ca. 86400 IN A 52.3.166.104



Hi Mark,

Interesting!

The only thing I can think of that may be causing this issue is that
this e-mail server makes use of SpamAssassin 4.0.0, which would be doing
lookups for DKIM, DMARC.

Has anyone noticed anything similar ?  It only seems to happen with the
socialinnovation.ca domain.

Thanks,

- J


--
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

Determining case of REFUSED queries

[J Doe]

Hi list,

I have BIND 9.18.29 validating recursive resolver running on OpenBSD
7.5.  This resolver performs resolution for a mail server.

Sometimes in my logs I will see the following:

17-Sep-2024 16:21:41.562 lame-servers: info: REFUSED unexpected
  RCODE resolving 'google._domainkey.socialinnovation.ca/TXT/IN':
  173.245.59.231#53

... but if I manually resolve the address with: dig against the resolver
on the command line of the mail server, no errors are recorded.

I'd like to determine why sometimes I receive this error.  I currently
have logging for this category of errors set to: severity info.  Should
I increase this or are there other ways to determine why resolution is
sometimes REFUSED ?

Thanks,

- J
--
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