long FQDN resolution

[DEMBLANS Mathieu]

Hello,
I have a question about mecanism for requests of long subdomains FQDN.
Our DNS, which is in recursive configuration, split long fqdn request with 
subdomains requests like :

Original request from the client to our recursive DNS : A a.b.c.d.example.com

Requests done by our DNS to the domain example.com NS:
A  _.c.d.example.com
A _b.c.d.example.com
A a.b.c.d.example.com

Is it a normal behaviour ?

This is only done for 4 levels domains (a.b.example.com for example) and more, 
not < normal > fqdn (ex : www.example.com).
What part of the configuration manage this mecanism ?
Is this really usefull ?

It is problematic for DNSBL requests because it generate a lot of useless 
requests and this kind of service look at the number of requests done (usage 
policy):

[cid:image002.png@01DBC5B3.192E1570]




-- 
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: long FQDN resolution

[Matus UHLAR - fantomas]

On 15.05.25 14:31, DEMBLANS Mathieu wrote:

I have a question about mecanism for requests of long subdomains FQDN.
Our DNS, which is in recursive configuration, split long fqdn request with 
subdomains requests like :

Original request from the client to our recursive DNS : A a.b.c.d.example.com

Requests done by our DNS to the domain example.com NS:
A  _.c.d.example.com
A _b.c.d.example.com
A a.b.c.d.example.com

Is it a normal behaviour ?

This is only done for 4 levels domains (a.b.example.com for example) and more, not 
< normal > fqdn (ex : www.example.com).
What part of the configuration manage this mecanism ?
Is this really usefull ?

It is problematic for DNSBL requests because it generate a lot of useless 
requests and this kind of service look at the number of requests done (usage 
policy):


It's been nearly a year since I asked the same, the results are in list 
archive:


https://lists.isc.org/pipermail/bind-users/2024-May/108537.html



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse
--
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: long FQDN resolution

[Matus UHLAR - fantomas]

On 15.05.25 14:31, DEMBLANS Mathieu wrote:

I have a question about mecanism for requests of long subdomains FQDN.
Our DNS, which is in recursive configuration, split long fqdn request with 
subdomains requests like :

Original request from the client to our recursive DNS : A a.b.c.d.example.com

Requests done by our DNS to the domain example.com NS:
A  _.c.d.example.com
A _b.c.d.example.com
A a.b.c.d.example.com

Is it a normal behaviour ?

This is only done for 4 levels domains (a.b.example.com for example) and more, not 
< normal > fqdn (ex : www.example.com).
What part of the configuration manage this mecanism ?
Is this really usefull ?

It is problematic for DNSBL requests because it generate a lot of useless 
requests and this kind of service look at the number of requests done (usage 
policy):


On 15.05.25 17:01, Matus UHLAR - fantomas wrote:
It's been nearly a year since I asked the same, the results are in 
list archive:


https://lists.isc.org/pipermail/bind-users/2024-May/108537.html


...and the solution was:

turn off QNAME minimisation on DNS servers used by mailservers for 
DNSBL/DNSWL checks.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS$\*.*
--
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: long FQDN resolution

[Marco Moock]

Am 15.05.2025 um 14:31:40 Uhr schrieb DEMBLANS Mathieu:

> It is problematic for DNSBL requests because it generate a lot of
> useless requests and this kind of service look at the number of
> requests done (usage policy):

Disable qname minimization for that.


-- 
Gruß
Marco

Send unsolicited bulk mail to 1747312300mu...@cartoonies.org
-- 
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: long FQDN resolution

[Greg Choules via bind-users]

I was beaten to it!
It's called QNAME minimisation and is specified here:
https://datatracker.ietf.org/doc/html/rfc9156

In BIND it can be disabled with this statement:
https://bind9.readthedocs.io/en/v9.20.8/reference.html#namedconf-statement-qname-minimization

Hope that helps, Greg

On Thu, 15 May 2025 at 15:32, DEMBLANS Mathieu  wrote:

> Hello,
>
> I have a question about mecanism for requests of long subdomains FQDN.
>
> Our DNS, which is in recursive configuration, split long fqdn request with
> subdomains requests like :
>
>
>
> Original request from the client to our recursive DNS : *A
> a.b.c.d.example.com *
>
>
>
> Requests done by our DNS to the domain example.com NS:
>
> *A  _.c.d.example.com *
>
> *A _b.c.d.example.com *
>
> *A a.b.c.d.example.com *
>
>
>
> Is it a normal behaviour ?
>
>
>
> This is only done for 4 levels domains (a.b.example.com for example) and
> more, not « normal » fqdn (ex : www.example.com).
>
> What part of the configuration manage this mecanism ?
>
> Is this really usefull ?
>
>
>
> It is problematic for DNSBL requests because it generate a lot of useless
> requests and this kind of service look at the number of requests done
> (usage policy):
>
>
>
>
>
>
>
>
>
>
> --
> 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: long FQDN resolution

[DEMBLANS Mathieu]

Thanks, I didn't find this information during my search in archives.
I will disable it.
 
 



-Message d'origine-
De : bind-users  De la part de Matus UHLAR - 
fantomas
Envoyé : jeudi 15 mai 2025 17:02
À : bind-users@lists.isc.org
Objet : Re: long FQDN resolution

On 15.05.25 14:31, DEMBLANS Mathieu wrote:
>I have a question about mecanism for requests of long subdomains FQDN.
>Our DNS, which is in recursive configuration, split long fqdn request with 
>subdomains requests like :
>
>Original request from the client to our recursive DNS : A a.b.c.d.example.com
>
>Requests done by our DNS to the domain example.com NS:
>A  _.c.d.example.com
>A _b.c.d.example.com
>A a.b.c.d.example.com
>
>Is it a normal behaviour ?
>
>This is only done for 4 levels domains (a.b.example.com for example) and more, 
>not < normal > fqdn (ex : www.example.com).
>What part of the configuration manage this mecanism ?
>Is this really usefull ?
>
>It is problematic for DNSBL requests because it generate a lot of useless 
>requests and this kind of service look at the number of requests done (usage 
>policy):

It's been nearly a year since I asked the same, the results are in list 
archive:

https://lists.isc.org/pipermail/bind-users/2024-May/108537.html



-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse
-- 
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: DNSVIZ errors

[akritrim® Intelligence™ via bind-users]

i didn’t receive your reply but saw this on lists archive so replying to 
you:




Do be aware that Ondrej is a member of ISC, the organization that 
develops
BIND. He is also one of the maintainers of the Debian release of BIND 
which

you are using.

Why should i be aware? Is he is a threat or something??

In general, claiming that everyone but you is wrong is not exactly a
teamplayer mentality, and creates aversion towards getting you the help 
you're
asking for. Not just Ondrej or the other developers ISC employs, the 
entire

list really.

I claim no such thing.

Or going even further than that, any list, any support channel. Not even 
just
voluntary ones like this, even paid support channels aren't going to 
like
customers who act like that. Those are paid to help you and to be nice 
to you,
yes, but don't be surprised if it diminishes the quality of the help you 
are

to receive.

I don’t share your views.

Do consider it, in any case.

I wont. from someone who cant even search the internet

N.B.: A trademark office allowed you to get a trademark on the term
"Intelligence"?

TM is not a LEGAL symbol. again learn to google and not hurl accusations 
in public and make a fool of yourself.



On 21/04/2025 8:25 pm, akritrim® Intelligence™ via bind-users wrote:
version: BIND 9.20.8-1+0~20250416.117+debian12~1.gbp1ea9dd-Debian 
(Stable Release)  (<>)
running on localhost: Linux x86_64 6.1.0-33-cloud-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.133-1 (2025-04-10)

boot time: Sun, 20 Apr 2025 15:40:59 GMT
last configured: Sun, 20 Apr 2025 15:40:59 GMT
configuration file: /etc/bind/named.conf
CPUs found: 1
worker threads: 1
number of zones: 10 (0 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
xfers first refresh: 0
soa queries in progress: 0
query logging is ON
response logging is OFF
memory profiling is INACTIVE
recursive clients: 0/900/1000
recursive high-water: 0
tcp clients: 0/150
TCP high-water: 25
server is up and running


is this any way related to this?

From 9.20.8 release notes:

Restore NSEC3 closest-encloser lookup improvements.

A performance improvement for finding the closest encloser when 
generating authoritative responses from NSEC3 zones was previously 
reverted after a bug was found that could trigger an assertion failure. 
([GL #4460], [GL #4950], and [GL #5108]) The bug has now been fixed, 
and the performance improvement has been restored. [GL #5204]




On 21/04/2025 7:12 pm, Mark Andrews wrote:

What does ‘rndc status’ return?

On 21 Apr 2025, at 13:05, akritrim® Intelligence™ via bind-users 
 wrote:


Thank you for your help. it does give insights into the problem.

if you check dnsviz history, this does not happen everytime.

the bind version is BIND 
9.20.8-1+0~20250416.117+debian12~1.gbp1ea9dd-Debian


obtained from: https://www.isc.org/download/  —->  
https://bind.debian.net/bind


there are no firewalls or load balancers. these are directly 
connected to internet. i was running BIND 9.18 official debian 
package and got no errors like this.



On 21/04/2025 4:46 am, Crist Clark wrote:
The version of BIND and where you got it would be a good start. Any 
load
balancers, firewalls, etc. between the server and internet that 
might touch

the DNS records?
True DNSSEC gurus please check my math.
DNSvis is correct. You're not sending the proper NSEC3 records. Like 
the
RFC says, "It takes three to tango," or NSEC3 denial of existence. 
You sent

two. For a name where two levels of label don't exists,
l5tz4.1i89a.akritrim.net
You should send back three NSEC3 records,
1) NSEC3 record that proves 1i89a.akritrim.net (
18QMAAOCT0HPNGCPD9MLONVAK13DS8HT) does not exist.
2) NSEC3 record for akritrim.net (N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P).
3) NSEC3 record proving the wildcard, *.akritrim.net (
6L23GRBE4JIMA1A0G8DSBBUT32V6VCO1), does not exist.
But you're not, you're only sending two,
N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P.akritrim.net. 600 IN NSEC3 1 0 0 -
QDO3A5R9G64L616H1K2FF3SUMFPPRV3J A NS SOA MX TXT  RRSIG DNSKEY
NSEC3PARAM CDS CDNSKEY CAA
67QJN06FLKRQCT38S4FF08EP31NDRL8S.akritrim.net. 600 IN NSEC3 1 0 0 -
6LPNNJIVL1267OV5QQSBFLMFIDHMHJ8P TXT RRSIG
Those are two I'd expect to see for (2) and (3), but where is (1)?
But it's weirder. For this name,
ebzoq.ik7ub.akritrim.net
You are sending three NSEC3, but one doesn't look like the right 
one. You

should send,
1) NSEC3 record that proves 1i89a.akritrim.net (
S2NOKIAA732BLNNSEMCJ8KV74H6ICUEP) does not exist.
2) NSEC3 record for akritrim.net (N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P).
3) NSEC3 record proving the wildcard, *.akritrim.net (
6L23GRBE4JIMA1A0G8DSBBUT32V6VCO1), does not exist.
But these get sent,
N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P.akritrim.net. 600 IN NSEC3 1 0 0 -
QDO3A5R9G64L616H1K2FF3SUMFPPRV3J A NS SOA MX TXT  RRSIG DNSKEY
NSEC3PARAM CDS CDNSKEY CAA
I559SEFHCJO35HED2LU4N68B44CA281V.akritrim.net. 600 IN NSEC3 1 0 0 -
KOGD0HOUD9R7BAB4LKQR2E9ALI57C7N0 A  RRSIG CAA
67QJN06FLKRQCT38S4FF08EP31NDRL8S.akritrim.net. 600 IN NSEC

Re: long FQDN resolution

[Benny Pedersen via bind-users]

Matus UHLAR - fantomas skrev den 2025-05-15 17:04:

turn off QNAME minimisation on DNS servers used by mailservers for 
DNSBL/DNSWL checks.


make a better rbldnsd that support qname :)

or dump zone from rbldnsd to bind.zone, the bind zone can be in sqlite 
to not be so memory hungry


or report to dnsbl that it does not support qname

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