Re: Response Policy Zone returns servfail for time.in Trigger

2023-04-09 Thread Lee
On 4/8/23, Fred Morris  wrote:
> Since one of the corner cases where RPZ is used is for mitigation of
> failures of legitimate resources, I have a question...
>
> On Sat, 8 Apr 2023, Ondřej Surý wrote:
>> time.in is currently broken - I am guessing this is the reason why are you
>> trying to rewrite the answers.
>>
>> RPZ does try to resolve the name first, and it fails, so there’s nothing
>> to rewrite.
>
> Does this mean that in the default configuration an e.g. A record in an
> RPZ overriding brokenness in the global DNS with a QNAME override might
> fail due to the same brokenness? As far as I know I've never experienced
> that.
>
> Going forward, what is anticipated to be the proper configuration for that
> scenario?

I haven't noticed any problems with this bit:

  response-policy { zone "thing1"; zone "thing2"; }
 break-dnssec yes
 recursive-only no
 qname-wait-recurse no;
  #enable rpz
  # By default, RPZ actions are applied only to DNS requests that either do not
  # request DNSSEC metadata (DO=0) or when no DNSSEC records are available for
  # request name in the original zone (not the response policy zone).
  # This default can be changed for all response policy zones in a view with a
  # break-dnssec yes clause. In that case, RPZ actions are applied regardless
  # of DNSSEC.

Regards,
Lee
-- 
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: Response Policy Zone returns servfail for time.in Trigger

2023-04-08 Thread isc



Hi,

You can use option qname-wait-recurse no;
to avoid for resolution waiting by Ondrej;

response-policy {
zone "local-redirect";
} qname-wait-recurse no;

In this combination, you will get redirect as I did below

% dig time.in @127.0.0.1

; <<>> DiG 9.16.37 <<>> time.in @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16906
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 76c28914f71577f801006431b8a864cf9cf0868502f1 (good)
;; QUESTION SECTION:
;time.in.   IN  A

;; ANSWER SECTION:
time.in.5   IN  A   127.0.0.1

;; ADDITIONAL SECTION:
local-redirect. 1   IN  SOA

Best Regards,
Peter

On 2023-04-08 20:28, bind-users-requ...@lists.isc.org wrote:


Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."

Today's Topics:

1. Re: Response Policy Zone returns servfail for time.in Trigger
(Matthew Gomez)
2. Re: Response Policy Zone returns servfail for time.in Trigger
(Fred Morris)

--

Message: 1
Date: Sat, 8 Apr 2023 14:25:57 -0400
From: Matthew Gomez 
To: Ond?ej Sur? 
Cc: bind-users@lists.isc.org
Subject: Re: Response Policy Zone returns servfail for time.in Trigger
Message-ID:

Content-Type: text/plain; charset="utf-8"

This works great!

Thanks,
Matt

On Sat, Apr 8, 2023 at 1:35 PM Ond?ej Sur?  wrote:


Hi,

time.in is currently broken - I am guessing this is the reason why are
you trying to rewrite the answers.

RPZ does try to resolve the name first, and it fails, so there?s 
nothing

to rewrite.

See the documentation
https://bind9.readthedocs.io/en/v9.18.13/reference.html#namedconf-statement-response-policy 
on

qname-wait-recurse and break-dnssec to turn off the default behavior.

Ondrej
--
Ond?ej Sur? ? ISC (He/Him)

My working hours and your working hours may be different. Please do 
not

feel obligated to reply outside your normal working hours.

On 8. 4. 2023, at 16:32, Matthew Gomez  wrote:

?

Hi, has anyone run into this before? It looks like a bug to me.

Summary

RPZ Returns a servfail when the trigger is "time.in"
<https://gitlab.isc.org/isc-projects/bind9/-/issues/4008#bind-version-used>BIND
version used

BIND 9.18.12-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)

<https://gitlab.isc.org/isc-projects/bind9/-/issues/4008#steps-to-reproduce>Steps
to reproduce

Configure a RPZ rule with the trigger as time.in (the action does not
seem to matter, I tried both CNAME . and A 1.1.1.1 both fail) Try to
resolve time.in against the bind server using dig, nslookup, etc a
servfail is returned

<https://gitlab.isc.org/isc-projects/bind9/-/issues/4008#what-is-the-current-bug-behavior>What
is the current *bug* behavior?

Bind returns a servfail when the trigger for an RPZ rule is "time.in" 
RPZ

works as expected for "tim.in" and "time.ind"

<https://gitlab.isc.org/isc-projects/bind9/-/issues/4008#what-is-the-expected-correct-behavior>What
is the expected *correct* behavior?

Bind should return the expected action (nxdomain, A record rewrite, 
etc)


<https://gitlab.isc.org/isc-projects/bind9/-/issues/4008#relevant-configuration-files>Relevant
configuration files

RPZ Zone File $TTL 86400 @ IN SOA localhost. root.localhost. ( 12 ; 
Serial
604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative 
Cache

TTL ; @ IN NS localhost.

time.in CNAME .

named.conf.local snippet zone "rpz.local" { type master; file
"/var/lib/bind/rpz.local"; allow-query { localhost; }; allow-transfer 
{

1.1.1.1; }; also-notify { 1.1.1.1; }; };

named.conf.options snippet //enable response policy zone. 
response-policy

{ zone "rpz.local"; };

<https://gitlab.isc.org/isc-projects/bind9/-/issues/4008#relevant-logs-andor-screenshots>Relevant
logs and/or screenshots

dig time.in @127.0.0.1

; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> time.in @127.0.0.1 ;;
global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, 
status:
SERVFAIL, id: 25602 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, 
AUTHORITY: 0,

ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE:
a197e43b329c51e70100643028c76d5822e3f9c2bbcb (good) ;; QUESTION
SECTION: ;time.in. IN A

;; Query tim

Re: Response Policy Zone returns servfail for time.in Trigger

2023-04-08 Thread Fred Morris
Since one of the corner cases where RPZ is used is for mitigation of 
failures of legitimate resources, I have a question...


On Sat, 8 Apr 2023, Ondřej Surý wrote:

time.in is currently broken - I am guessing this is the reason why are you 
trying to rewrite the answers.

RPZ does try to resolve the name first, and it fails, so there’s nothing to 
rewrite.


Does this mean that in the default configuration an e.g. A record in an 
RPZ overriding brokenness in the global DNS with a QNAME override might 
fail due to the same brokenness? As far as I know I've never experienced 
that.


Going forward, what is anticipated to be the proper configuration for that 
scenario?


Thanks...

--

Fred Morris
-- 
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: Response Policy Zone returns servfail for time.in Trigger

2023-04-08 Thread Matthew Gomez
This works great!

Thanks,
Matt

On Sat, Apr 8, 2023 at 1:35 PM Ondřej Surý  wrote:

> Hi,
>
> time.in is currently broken - I am guessing this is the reason why are
> you trying to rewrite the answers.
>
> RPZ does try to resolve the name first, and it fails, so there’s nothing
> to rewrite.
>
> See the documentation
> https://bind9.readthedocs.io/en/v9.18.13/reference.html#namedconf-statement-response-policy
>  on
> qname-wait-recurse and break-dnssec to turn off the default behavior.
>
> Ondrej
> --
> Ondřej Surý — ISC (He/Him)
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> On 8. 4. 2023, at 16:32, Matthew Gomez  wrote:
>
> 
>
> Hi, has anyone run into this before? It looks like a bug to me.
>
>
> Summary
>
> RPZ Returns a servfail when the trigger is "time.in"
> BIND
> version used
>
> BIND 9.18.12-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)
>
> Steps
> to reproduce
>
> Configure a RPZ rule with the trigger as time.in (the action does not
> seem to matter, I tried both CNAME . and A 1.1.1.1 both fail) Try to
> resolve time.in against the bind server using dig, nslookup, etc a
> servfail is returned
>
> What
> is the current *bug* behavior?
>
> Bind returns a servfail when the trigger for an RPZ rule is "time.in" RPZ
> works as expected for "tim.in" and "time.ind"
>
> What
> is the expected *correct* behavior?
>
> Bind should return the expected action (nxdomain, A record rewrite, etc)
>
> Relevant
> configuration files
>
> RPZ Zone File $TTL 86400 @ IN SOA localhost. root.localhost. ( 12 ; Serial
> 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache
> TTL ; @ IN NS localhost.
>
> time.in CNAME .
>
> named.conf.local snippet zone "rpz.local" { type master; file
> "/var/lib/bind/rpz.local"; allow-query { localhost; }; allow-transfer {
> 1.1.1.1; }; also-notify { 1.1.1.1; }; };
>
> named.conf.options snippet //enable response policy zone. response-policy
> { zone "rpz.local"; };
>
> Relevant
> logs and/or screenshots
>
> dig time.in @127.0.0.1
>
> ; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> time.in @127.0.0.1 ;;
> global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
> SERVFAIL, id: 25602 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0,
> ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE:
> a197e43b329c51e70100643028c76d5822e3f9c2bbcb (good) ;; QUESTION
> SECTION: ;time.in. IN A
>
> ;; Query time: 292 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN:
> Fri Apr 07 10:29:27 EDT 2023 ;; MSG SIZE rcvd: 64
>
> LOG Apr 7 10:30:37 server named[941]: client @0x7f74a80d03b8
> 127.0.0.1#34415 (time.in): query failed (failure) for time.in/IN/A at
> query.c:7775
> --
> 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
>
>
-- 
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: Response Policy Zone returns servfail for time.in Trigger

2023-04-08 Thread Ondřej Surý
Hi,time.in is currently broken - I am guessing this is the reason why are you trying to rewrite the answers.RPZ does try to resolve the name first, and it fails, so there’s nothing to rewrite.See the documentation https://bind9.readthedocs.io/en/v9.18.13/reference.html#namedconf-statement-response-policy on qname-wait-recurse and break-dnssec to turn off the default behavior.Ondrej--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 8. 4. 2023, at 16:32, Matthew Gomez  wrote:Hi, has anyone run into this before? It looks like a bug to me. SummaryRPZ Returns a servfail when the trigger is "time.in"BIND version usedBIND 9.18.12-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)Steps to reproduceConfigure a RPZ rule with the trigger as time.in (the action does not seem to matter, I tried both CNAME . and A 1.1.1.1 both fail) Try to resolve time.in against the bind server using dig, nslookup, etc a servfail is returnedWhat is the current bug behavior?Bind returns a servfail when the trigger for an RPZ rule is "time.in" RPZ works as expected for "tim.in" and "time.ind"What is the expected correct behavior?Bind should return the expected action (nxdomain, A record rewrite, etc)Relevant configuration filesRPZ Zone File $TTL 86400 @ IN SOA localhost. root.localhost. ( 12 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL ; @ IN NS localhost.time.in CNAME .named.conf.local snippet zone "rpz.local" { type master; file "/var/lib/bind/rpz.local"; allow-query { localhost; }; allow-transfer { 1.1.1.1; }; also-notify { 1.1.1.1; }; };named.conf.options snippet //enable response policy zone. response-policy { zone "rpz.local"; };Relevant logs and/or screenshotsdig time.in @127.0.0.1; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> time.in @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25602 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: a197e43b329c51e70100643028c76d5822e3f9c2bbcb (good) ;; QUESTION SECTION: ;time.in. IN A;; Query time: 292 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri Apr 07 10:29:27 EDT 2023 ;; MSG SIZE rcvd: 64LOG Apr 7 10:30:37 server named[941]: client @0x7f74a80d03b8 127.0.0.1#34415 (time.in): query failed (failure) for time.in/IN/A at query.c:7775

-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- 
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