Re: Resolving and caching illegal names

2023-01-25 Thread John Thurston
I hadn't had enough coffee when I wrote that. I was doing in-addr.arpa 
translation in my head and confusing what was the TLD of the query being 
submitted. If a customer is stupid enough to ask for an A-record for 
10.1.2.3, then the TLD of that name is "3", not "10" . . duh.


So to make the RPZ work, I needed to stuff the zone file with 256 new 
entries. I did this by dusting off my knowledge of the GENERATE 
directive (which involved RTFM):


   $GENERATE 0-255 *.$ CNAME   .

I also needed to populate the "validate-except" option with 256 new 
entries. I could find no elegant way to generate, abstract, or 'include' 
this, so just needed to put the long string of characters inline:


   0; 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; . . .

and it now behaves as desired; returning an unvalidated NXDOMAIN for 
queries for ip addresses.


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska

On 1/25/2023 8:36 AM, John Thurston wrote:


Off-list, it was suggested to me that I _could_ handle this in my RPZ, 
by enumerating all 255 illegal TLDs (e.g. *.10  CNAME . )


I tried this, and it works as expected when dnssec validation is 
disabled (either globally, or with "validate-except". My idea right 
now is I can enumerate TLD of the numerics I see in my logs, and 
ignore the rest. I think this will get me what I want, at a level of 
complexity I can accept.
-- 
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: Resolving and caching illegal names

2023-01-25 Thread John Thurston

- Why *must* you forward everything to Akamai?


I am forced to "forward only;" to Akamai for all external queries. It 
hasn't always been this way, but the decision was made "above my pay 
grade", and it is not open to negotiation.



- Was that a real example of a daft query: 10.11.12.13 type A?


"10.11.12.13 is, indeed, a query I found in my log.


what's the issue with returning SERVFAIL?


On my validating "recursive" servers, "SERVFAIL" is the response from 
_my_ server. That is the result of Akamai saying "Here's your answer!" 
and my server going through the work of trying to validate it (and failing).


On my non-validating "recursive" servers, I send back the answer Akamai 
sends me:



;; ANSWER SECTION:
10.11.12.13.    10  IN  A   10.11.12.13


I think SERVFAIL is the correct answer for all of these queries. I do 
not want to encourage any customers in thinking they can get an address 
back from me by asking for the address of an address.




- Do Akamai have any knobs you can tweak


{chuckle} I'm not allowed in the control room. And Akamai's response to 
my question was quoted in my original message. From their perspective, 
this behavior is a feature, not a defect. I don't expect them to let 
their customer disable their "features". If I want to change this 
behavior, I'm going to have to do it within my sphere of influence.


Off-list, it was suggested to me that I _could_ handle this in my RPZ, 
by enumerating all 255 illegal TLDs (e.g. *.10  CNAME . )


I tried this, and it works as expected when dnssec validation is 
disabled (either globally, or with "validate-except". My idea right now 
is I can enumerate TLD of the numerics I see in my logs, and ignore the 
rest. I think this will get me what I want, at a level of complexity I 
can accept.


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska

On 1/24/2023 10:26 PM, Greg Choules wrote:

- Why *must* you forward everything to Akamai?
- Was that a real example of a daft query: 10.11.12.13 type A? If not, 
do you have some real examples of queries being made to your servers 
please?
- Notwithstanding the nature of these illegal queries, if they *are* 
illegal (or misguided, or errors, or malicious, or whatever - anything 
but valid), what's the issue with returning SERVFAIL? GIGO Or does 
that then prejudice genuine queries, for some reason?

- Are you *only* forwarding to Akamai?
- Do you have "forward only;" or "forward first;"?
- Do Akamai have any knobs you can tweak (I believe they have a 
customer web portal for viewing/changing settings?) that would make 
them behave like an RFC compliant DNS server?-- 
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: Resolving and caching illegal names

2023-01-24 Thread Greg Choules via bind-users
Hi John.
A few questions, if I may.
- Why *must* you forward everything to Akamai?
- Was that a real example of a daft query: 10.11.12.13 type A? If not, do
you have some real examples of queries being made to your servers please?
- Notwithstanding the nature of these illegal queries, if they *are*
illegal (or misguided, or errors, or malicious, or whatever - anything but
valid), what's the issue with returning SERVFAIL? GIGO Or does that then
prejudice genuine queries, for some reason?
- Are you *only* forwarding to Akamai?
- Do you have "forward only;" or "forward first;"?
- Do Akamai have any knobs you can tweak (I believe they have a customer
web portal for viewing/changing settings?) that would make them behave like
an RFC compliant DNS server?

Cheers, Greg


On Tue, 24 Jan 2023 at 21:17, John Thurston 
wrote:

> My "resolvers" running BIND 9.18.10 and 9.16.36, accept and attempt to
> resolve queries for illegal names. They will cache answers for these names,
> and answer from cache when asked. What's the thinking here?
>
> I suppose it could be, "The specifications of what is a legal name may
> change with time, and we don't want to burden the resolver code by asking
> it to validate the string before trying to resolve it."
>
> This comes up because my "resolvers" don't actually resolve. All they are
> allowed to do is forward external queries to Akamai, and accept the
> response from Akamai. And Akamai (thank you very much), is happy to accept
> queries like "What is the A-record for 10.11.12.13?" and reply with "The
> answer is 10.11.12.13, and is good for 10 seconds."
>
> Akamai's explanation for this behavior is, ..." the query was made in
> error (likely/maybe meant to be type "PTR") and we are trying to save the
> resolver from doing the work a query like this would entail."
>
> But what it really means is my validating "resolver" then does the work of
> trying to validate the reply it got. It is unable to do so, and returns a
> SERVFAIL to the customer.
>
> I haven't yet tried, but I don't expect I can define an RPZ to trap such
> illegal names. Can I? If I could, it would reduce the traffic to Akamai,
> and the number of validations I'm trying to do.
>
>
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
>
> --
> 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: Resolving and caching illegal names

2023-01-24 Thread Marco
Am 24.01.2023 um 12:15:58 Uhr schrieb John Thurston:

> This comes up because my "resolvers" don't actually resolve. All they 
> are allowed to do is forward external queries to Akamai, and accept
> the response from Akamai. And Akamai (thank you very much), is happy
> to accept queries like "What is the A-record for 10.11.12.13?" and
> reply with "The answer is 10.11.12.13, and is good for 10 seconds."
> 
> Akamai's explanation for this behavior is, ..." the query was made in 
> error (likely/maybe meant to be type "PTR") and we are trying to save 
> the resolver from doing the work a query like this would entail."

Then Akamai is doing nasty things. Why don't they answer the correct
answer

.   3600IN  SOA a.root-servers.net.
nstld.verisign-grs.com. 2023012500 1800 900 604800 86400

and let applications fail that don't query PTR records in
in-addr.apra/ip6.arpa?
-- 
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


Resolving and caching illegal names

2023-01-24 Thread John Thurston
My "resolvers" running BIND 9.18.10 and 9.16.36, accept and attempt to 
resolve queries for illegal names. They will cache answers for these 
names, and answer from cache when asked. What's the thinking here?


I suppose it could be, "The specifications of what is a legal name may 
change with time, and we don't want to burden the resolver code by 
asking it to validate the string before trying to resolve it."


This comes up because my "resolvers" don't actually resolve. All they 
are allowed to do is forward external queries to Akamai, and accept the 
response from Akamai. And Akamai (thank you very much), is happy to 
accept queries like "What is the A-record for 10.11.12.13?" and reply 
with "The answer is 10.11.12.13, and is good for 10 seconds."


Akamai's explanation for this behavior is, ..." the query was made in 
error (likely/maybe meant to be type "PTR") and we are trying to save 
the resolver from doing the work a query like this would entail."


But what it really means is my validating "resolver" then does the work 
of trying to validate the reply it got. It is unable to do so, and 
returns a SERVFAIL to the customer.


I haven't yet tried, but I don't expect I can define an RPZ to trap such 
illegal names. Can I? If I could, it would reduce the traffic to Akamai, 
and the number of validations I'm trying to do.




--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
-- 
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