Use UDP for (small) incremental zone transfers?

[Jesus Cea]

I have a dns zone with many dns updates per minute. The updates are 
tiny, like 2-3 records, <500 bytes in total.


Currently my secondaries receive a NOTIFY and they do a TCP connection 
to request a incremental zone transfer. We know that TCP is "heavy" and 
the data I need to transfer is tiny before shutting down the TCP connection.


Is there any way to do incremental zone transfer via UDP and, if the 
size is too big (>1232 bytes), fall back to TCP?


Thanks!

PS: I protect everything using TSIG.

--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: Use UDP for (small) incremental zone transfers?

[Jesus Cea]

On 13/1/23 7:12, Greg Choules via bind-users wrote:

Hi Jesus.
No. Zone Transfer always uses TCP. Is it really that much of an overhead 
for you?


Not now, but it could be in the future, with many secondaries and many 
(tiny) updates per minute.


Per your answer, I understand that zone transfers in current bind are 
TCP-only.


Thanks.

--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

Incremental transfers generate complete zone reloading

[Jesus Cea]

I have a huge zone receiving a constant flow of small dns updates. My 
secondaries receive notifications and transfer the zone incrementally. 
Cool, everything works as expected.


Nevertheless, I see this lines in my logs, constantly (every time a 
change arrives incrementally):


"""
15-Jan-2023 17:49:47.662 general: info: rpz: rpz.local: new zone version 
came too soon, deferring update for 28 seconds
15-Jan-2023 17:49:54.716 notify: info: client @11f80268 X.X.X.X#63514: 
received notify for zone 'rpz.local'
15-Jan-2023 17:49:54.716 general: info: zone rpz.local/IN: notify from 
X.X.X.X#63514: serial 8991

15-Jan-2023 17:50:15.662 general: info: rpz: rpz.local: reload start
15-Jan-2023 17:50:16.884 general: info: rpz: rpz.local: reload done
"""

Ok, my updates are coming too fast (first line). No problem, the 
secondary will eventually retrieve the changes. What worries me is the 
last couple of lines: The rpz zone (big, around 800.000 domains) is 
being reloaded constantly and it takes a couple of seconds eating CPU, 
when the incremental changes are actually pretty tiny.


I would guess the incremental changes would do an incremental change in 
memory structures, not a full zone reload taking a couple of seconds and 
sucking an entire CPU core.


My secondary configuration is pretty trivial:

"""
[...]
  response-policy {
zone "rpz.local" policy nxdomain;
  };

[...]

zone "rpz.local" {
  type slave;
  file "../secundarios/db.rpz.local";
  allow-query { 127.0.0.1; };
  allow-transfer { none; };
  masters {
X.X.X.X;
  };
};

"""

Is this maybe related with being a "response-policy" zone? If this is 
the case and a malware RPZ is going to be BIG by definition, what would 
be the suggested approach?


Thanks!

PS: I have not tried alternative secondary storage backends yet, like 
"map". I am trying to understand what is going on first.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

DNSTAP doesn't purge old dnstap files

[Jesus Cea]

Hi everybody.

Bind 9.16 here.

I have this configuration for DNSTAP:

"""
  dnstap {auth; client; resolver; forwarder;};
  dnstap-output file "/var/cache/bind/dnstap.tap" size 100M versions 
100 suffix timestamp;

"""

The "dnstap.tap" is correctly moved to "dnstap.tap.TIMESTAMP" a new 
"dnstap.tap" file is created when the old one reaches 100MB in size, but 
bind is not purging old "dnstap.tap.TIMESTAMP" files when their count 
goes over 100. It doesn't delete all files at all.


I configured logging as:

"""
  channel dnstaplog {
file "dnstap.log" versions 10 size 5m;
print-time yes;
print-category yes;
severity debug;
print-severity yes;
  };

  category dnstap { dnstaplog; };
"""

I only see in the logs when a new "dnstap.tap" file is created, but I 
don't see anything related to deleting old files, or errors trying to do so:


"""
...
21-Mar-2023 18:44:31.327 dnstap: info: rolling dnstap destination 
'/var/cache/bind/dnstap.tap'
21-Mar-2023 18:57:12.937 dnstap: info: rolling dnstap destination 
'/var/cache/bind/dnstap.tap'
21-Mar-2023 19:09:23.546 dnstap: info: rolling dnstap destination 
'/var/cache/bind/dnstap.tap'

...
"""

Any suggestion?

PS: Previously I was using "increment" instead of timestamped 
"dnstap.tap" files and it worked fine (well, reusing/overwriting old 
files, not deleting them).


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

Patch provided, please review!: Re: DNSTAP doesn't purge old dnstap files

[Jesus Cea]

On 21/3/23 23:38, Jesus Cea wrote:

Hi everybody.

Bind 9.16 here.

I have this configuration for DNSTAP:

"""
   dnstap {auth; client; resolver; forwarder;};
   dnstap-output file "/var/cache/bind/dnstap.tap" size 100M versions 
100 suffix timestamp;

"""

The "dnstap.tap" is correctly moved to "dnstap.tap.TIMESTAMP" a new 
"dnstap.tap" file is created when the old one reaches 100MB in size, but 
bind is not purging old "dnstap.tap.TIMESTAMP" files when their count 
goes over 100. It doesn't delete all files at all.


I have invested an afternoon debugging this and I have a diagnostic and 
a trivial patch: Please, review: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/3959


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

[Jesus Cea]

I am getting errors "Name huawei.com (SOA) not subdomain of zone 
cloud.huawei.com". The problem raises when requesting  on 
oauth-login.cloud.huawei.com . The problem was described in the mailing 
list:


https://lists.isc.org/pipermail/bind-users/2021-January/104064.html

BIND is replying with a SERVFAIL. This is correct and appropriate. 
Nevertheless resolvers like 8.8.8.8, 1.1.1.1, 9.9.9.9 and many (most) 
other are not doing that SOA verification, so for users we are the 
guilty, not Huawey, because "using Google it works!". In fact, we have a 
big customer phone app failing because of this (yes, this seems to be a 
bug with that app but, again, "with google it works!").


What can we do? Is possible to disable that check in bind?

We are using 9.16. We could upgrade to 9.18, if needed.

Thanks.

--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

[Jesus Cea]

On 1/6/23 17:00, Ondřej Surý wrote:

 From top of my head - try disabling QNAME minimization.


I don't see the relevance but I tried "qname-minimization off" in my 
configuration. No changes, I still see the SERVFAIL.


I insist this is not a bug in BIND. The original domain is 
misconfigured. But this misconfiguration is pretty common and resolvers 
like 8.8.8.8, 1.1.1.1, 9.9.9.9 just ignore the issue and provide a nice 
(and wrong, I agree) "NOERROR" reply. They are faulty, not BIND. But my 
clients do not agree: "it works fine with google/cloudflare/infoblox, 
you give back a SERVFAIL, goodbye until you fix it, rookie!".


You can see the issue yourself doing:

dig -t  @YOUR_DNS_SERVER_IP oauth-login.cloud.huawei.com

If you are using BIND you will see a SERVFAIL. Then try with 8.8.8.8, 
1.1.1.1, 9.9.9.9 and whoever other open DNS resolver you know about. 
Compare the results.


All big ISP resolvers I tried in Spain give back a NOERROR. Universities 
too.


This issue was described perfectly in this mailing list a couple of 
years ago: 
https://lists.isc.org/pipermail/bind-users/2021-January/104064.html


This huawei misconfiguration is quite common around and since big DNS 
players just accept it, I am having a quite hard time defending that 
BIND is actually doing the right thing.


For instance, a few examples from my logs(only a few seconds of them!). 
There are MANY MANY more. Try requesting  for (using your BIND 
server and the 8.8.8.8):


aes.orange.es
api.mediago.io
appmimovistar.movistar.es
eneotecnologia.com
epns.eset.com
t3pub.movistar.es
trace-eu.mediago.io
trace.mediago.io

I can provide a quite long list if requested.

Studying the sourcecode, I see this in "lib/dns/resolver.c":

"""
if (!dns_name_issubdomain(&fctx->name, &fctx->domain)) {
dns_name_format(&fctx->domain, buf, sizeof(buf));
UNEXPECTED_ERROR(__FILE__, __LINE__,
 "'%s' is not subdomain of '%s'", fctx->info,
 buf);
result = ISC_R_UNEXPECTED;
goto cleanup_fcount;
}
"""

Nothing there looks like can be configured, beside just deleting that 
code and recompiling.


There are QNAME minimization code down the same function, but the code 
doesn't reach there, the error is generated before getting there. So no, 
"qname-minimization off" doesn't solve this.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

[Jesus Cea]

On 1/6/23 17:00, Ondřej Surý wrote:

 From top of my head - try disabling QNAME minimization.


I don't see the relevance but I tried "qname-minimization off" in my 
configuration. No changes, I still see the SERVFAIL.


I insist this is not a bug in BIND. The original domain is 
misconfigured. But this misconfiguration is pretty common and resolvers 
like 8.8.8.8, 1.1.1.1, 9.9.9.9 just ignore the issue and provide a nice 
(and wrong, I agree) "NOERROR" reply. They are faulty, not BIND. But my 
clients do not agree: "it works fine with google/cloudflare/infoblox, 
you give back a SERVFAIL, goodbye until you fix it, rookie!".


You can see the issue yourself doing:

dig -t  @YOUR_DNS_SERVER_IP oauth-login.cloud.huawei.com

If you are using BIND you will see a SERVFAIL. Then try with 8.8.8.8, 
1.1.1.1, 9.9.9.9 and whoever other open DNS resolver you know about. 
Compare the results.


All big ISP resolvers I tried in Spain give back a NOERROR. Universities 
too.


This issue was described perfectly in this mailing list a couple of 
years ago: 
https://lists.isc.org/pipermail/bind-users/2021-January/104064.html


This huawei misconfiguration is quite common around and since big DNS 
players just accept it, I am having a quite hard time defending that 
BIND is actually doing the right thing.


For instance, a few examples from my logs(only a few seconds of them!). 
There are MANY MANY more. Try requesting  for (using your BIND 
server and the 8.8.8.8):


aes.orange.es
api.mediago.io
appmimovistar.movistar.es
eneotecnologia.com
epns.eset.com
t3pub.movistar.es
trace-eu.mediago.io
trace.mediago.io

I can provide a quite long list if requested.

Studying the sourcecode, I see this in "lib/dns/resolver.c":

"""
if (!dns_name_issubdomain(&fctx->name, &fctx->domain)) {
dns_name_format(&fctx->domain, buf, sizeof(buf));
UNEXPECTED_ERROR(__FILE__, __LINE__,
 "'%s' is not subdomain of '%s'", fctx->info,
 buf);
result = ISC_R_UNEXPECTED;
goto cleanup_fcount;
}
"""

Nothing there looks like can be configured, beside just deleting that 
code and recompiling.


There are QNAME minimization code down the same function, but the code 
doesn't reach there, the error is generated before getting there. So no, 
"qname-minimization off" doesn't solve this.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

[Jesus Cea]

On 2/6/23 4:25, Mark Andrews wrote:

Yep, some people just don’t take care with delegations.  Complain to Huawei.
Complain to the other companies you list in your followup email.

All it takes to fix this is to change the name of the zone on the child servers
(ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com”
to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone
if they are fully qualified.  If there are other delegations from huawei.com
for other sub zones to these servers they will also need to be instantiated.

It’s maybe 10 minute work for each subdomain to fix.  It just requires someone
to do the work.


I sympathize. Expertise and caring for the job is something the world is 
losing fast and few people care at all. Complaining to business is not 
going to work, because this misconfiguration works fine for 99.9% of 
their users, clients of more "lax" DNS resolvers.


What I get from your reply is that BIND is not expected to do anything 
about this. It is a bit disappointed but I agree that BIND is doing the 
right thing. Too bad big players don't care. But I need to "solve" this, 
so dropping BIND (nooo!) or patching software is on my table now.



When people come to you and say that it works with Google, et al. point them at
https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say
“Here is a DNS configuration testing site and it reports the zone as broken, you
need to take it up with the company."


"Whatever, Google works and you don't. You sucks!". Few people care 
about doing the right thing if crap works for them. If only 8.8.8.8 
cared and gave back SERVFAIL as it should, everybody would fix her 
configuration immediately. Postel law [*] was a mistake (be strict when 
sending and forgiving when receiving). Nice advice, awful consequences 
we will pay forever.


https://en.wikipedia.org/wiki/Robustness_principle

--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

[Jesus Cea]

On 2/6/23 10:38, Cathy Almond wrote:

Has this just started - as in, it worked before ... when?


No idea. We have been biten by this because a new client. The issue 
could be for ages, no idea.


It sounds like 'they changed something', possibly by accident (maybe 
adding more servers or changing their provisioning tools?), so it 
wouldn't hurt to let them know directly.


I tried a handful of Huawei emails. No reply so far.

--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

[Jesus Cea]

On 2/6/23 7:59, Nick Tait via bind-users wrote:

On 2/06/23 15:02, Jesus Cea wrote:
What I get from your reply is that BIND is not expected to do anything 
about this. It is a bit disappointed but I agree that BIND is doing 
the right thing. Too bad big players don't care. But I need to "solve" 
this, so dropping BIND (nooo!) or patching software is on my table now. 


Don't know if it will work, but something to try could be to create a 
forwarding zone for each of the zones that is having this problem, and 
forward the queries to (e.g.) Google? In theory that would cause BIND to 
ask Google for the answer instead of working it out for itself?


It doesn't work, because Google (8.8.8.8) is giving back exactly what 
huawei provides (a NODATA reply, with an invalid SOA in the 
authoritative section) and BIND "verifying" resolver detects the problem 
and reply to the DNS client with a (correct but inconvenient) SERVFAIL.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

[Jesus Cea]

On 2/6/23 4:25, Mark Andrews wrote:

Yep, some people just don’t take care with delegations.  Complain to Huawei.
Complain to the other companies you list in your followup email.


Huawei is already notified, days ago. No reply and no changes so far.


The list is quite long, in a few minutes I have a 859 unique requests 
with the same configuration error. Interestingly, quite a few from 
"ntp.org". For example:


resolver: notice: DNS format error from 102.130.49.148#53 resolving 
0.centos.pool.ntp.org/ for #YYY Name pool.ntp.org (SOA) not 
subdomain of zone centos.pool.ntp.org -- invalid response


resolver: notice: DNS format error from 102.130.49.148#53 resolving 
0.debian.pool.ntp.org/ for #YYY Name pool.ntp.org (SOA) not 
subdomain of zone debian.pool.ntp.org -- invalid response


I just sent an email to NTP mailing list.

Lenovo is guilty too:

resolver: notice: DNS format error from 103.30.232.121#53 resolving 
ibase.gtm.lenovo.com/ for #YYY Name lenovo.com (SOA) not 
subdomain of zone gtm.lenovo.com -- invalid response


qq.com too:

resolver: notice: DNS format error from 121.51.160.207#53 resolving 
ns3.qq.com/ for : Name qq.com (SOA) not subdomain of zone 
ns3.qq.com -- invalid response


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

Reuse RPZ zones between views

[Jesus Cea]

My RPZ zones are quite big, and I would like to be able to reuse them in 
several views sharing the memory instead of independent data structures.


I thought that zone "in-view" would work, but it doesn't.

I am doing something like:

"""
view honeypot {
match-clients { honeypot; };
allow-recursion { honeypot; };

zone "rpz" {
  type slave;
  [...];
};
response-policy {
zone "rpz" policy disabled; //cname prueba.xx.xx;
  } break-dnssec yes;
};

view default {
match-clients { any; };
allow-recursion { any; };
zone "rpz" { in-view "honeypot"; };
response-policy {
  zone "rpz";
} break-dnssec yes;
};
"""

Trying to activate that configuration produce an error:

"""
response-policy zone 'rpz' for view default is not a primary or 
secondary zone

"""

But "rpz" is secondary (slave) in "honeypot"
I would think this a bug in bind?. I am using version 9.18.25.

Any suggestion beside loading the "rpz" zone separately in each view?. 
That would explode my memory usage (I have quite a few views).


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: Reuse RPZ zones between views

[Jesus Cea]

On 12/6/24 21:46, Mark Andrews wrote:

Have you read the fine documentation on BIND where it is stated this is not 
(currently) possible?

If you want to extend named to support this we would be happy to review a 
change request.  It is complicated however which is why it has not been done.


Oh, a single line in page 257: "An in-view zone cannot be used as a 
response policy zone.". Acked.


Ok.

I have checked the source code in librpz.h and dnsrps.c. Quite scary...

So, I have a question about what are the best practices to configure 
different RPZs for different clients without paying the overhead of 
loading multiple times the same RPZ. With 8 different RPZ, there are 256 
combinations (views) and the memory overhead would be RPZx128!


I wonder about librpz and dnsrps. The source is quite difficult and 
opaque, and I see no documentation anywhere beside a passing mention to 
"dnsrps-enable" and "dnsrps-options". Any hint?


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

Information about dnsrps, fastRPZ and similar modules

[Jesus Cea]

Investigating about non trivial RPZ configurations, I noticed a huge 
block on bind 9.12 to provide DNSRPS, an API for external RPZ providers. 
Nevertheless, the code is complicated and there is no documentation. 
Checking around I only found a RPZ module provided by the same people 
people that implemented the api: FastRPZ. That module is not open source.


I wrote to the company, but it was bought by another one and the 
original email address is bouncing. According to this recently archived 
webpage (a year ago) 
, 
I saw this:


"""
If you have a current BIND Support Subscription, you may be eligible to 
get FastRPZ free of charge. Please contact ISC Support to request access 
to FastRPZ.

"""

Any information? Any alternative?

Any other module using DNSRPS?. Any documentation at all?

Thanks.

PS: Apparently the configuration of this mailing list is not compatible 
with DMARC. Please, configure the mailing list to be compatible. You are 
using mailman, I manage several mailman mailing lists myself. In the 
administrative interface, go to "privacy options -> sender filters" and 
check out DMARC options. Most of mailing list admins set it to "Munge from".


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

How to *require* TSIG for NOTIFY

[Jesus Cea]

Hi everybody,

I can configure my bind master to send TSIG in the NOTIFY messages, but 
I am not able to configure secondaries to *ONLY* allow NOTIFY with a 
valid TSIG.


In the slave zone config I have something like:

"""
zone "XXX" {
  type slave;
...
  allow-notify { key "KEY_TSIG"; };
  masters {
IP;
  };
};
"""

The slave accepts the NOTIFY coming from "IP" (the master IP address), 
in both cases, with TSIG and with no TSIG. That is, it seems like ips 
listed in "masters" are not required to TSIG at all.


The log shows this fact:

Master configured with TSIG:

"""
15-Nov-2022 01:48:50.961 notify: info: client @268b268 
IP#57901/key_tsig: received notify for zone 'XXX.local': TSIG 'key_tsig'

"""

Master configured with no TSIG:

"""
15-Nov-2022 02:15:30.701 notify: info: client @4074268 IP#32138: 
received notify for zone 'XXX.local'

"""

So, I can control whenever the master send notifies with and without 
TSIG,  but slaves just don't care to verify it (if the notify comes from 
a "masters" source).


Checking documentation around, I read this:

"""
allow-notify applies to slave zones only and defines a match list, for 
example, IP address(es) that are allowed to NOTIFY this server and 
implicitly update the zone in addition to those hosts defined in the 
masters option for the zone. The default behaviour is to allow zone 
updates only from the masters IP(s). This statement may be used in a 
zone, view or global options clause.

"""

It seems that whatever I specify in "allow-notify", "masters" are always 
allowed to notify without TSIG.


Given that NOTIFY is UDP and source spoofing is so easy, I would like to 
be able to *REQUIRE* TSIG even for "masters".


Is this something I can configure in bind? Is this something 
unrealistic/too paranoid for my own good?


Thanks.

--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: How to *require* TSIG for NOTIFY

[Jesus Cea]

On 15/11/22 3:30, Mark Andrews wrote:


NOTIFY is a hint for the secondary to perform a SOA refresh query sooner than 
the SOA query triggered by REFRESH and RETRY.  Those queries are rate limited.  
Additionally multiple notify messages often coalesce
into one action as the server is waiting to send or is waiting for responses 
when they arrive.


I understand. I interpret your words as "even if you are getting fake 
notifies, the cost is quite small". That is nice.I am being possibly too 
paranoid.



While I don’t see the need, adding an 'allow-notify-explicit ;’ could be 
added to ignore the primaries
list and only use the allow-notify acl.


Could you possibly send me an URL documenting 'allow-notify-explicit' 
clause?. I am not able to find anything relevant online. I don't ever 
see anything related in 9.16.34 source code:


"""
jcea@jcea:/tmp/ram/bind-9.16.34$ find . -name "*.c" -exec grep -i 
"allow-notify-" {} \; -print

"""

Thanks!

--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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: How to *require* TSIG for NOTIFY

[Jesus Cea]

On 15/11/22 5:40, Ondřej Surý wrote:

It’s `also-notify ;` and `notify explicit;`

The online documentation is here: 
https://bind9.readthedocs.io/en/v9_16_34/reference.html 



That configuration affects to the primary, I don't see how it affects 
the slaves.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

Providing AD flag for authoritative domains

[Jesus Cea]

I have a validating DNSSEC bind server. I get AD (Authenticated Data) 
flag when requesting details from a DNSSEC protected domain. Good.


The point is that when the requested DNS name belongs to a domain with 
this server is authoritative and that domain is DNSSEC enabled, no AD 
flag is provided in the answer. I guess this is because bind is replying 
with DNSSEC data but it doesn't follow that DNSSEC delegation tree in 
order to verify that everything is OK and so it doesn't signal safety 
with the AD flag.


Is there any way to configure bind to verify DNSSEC integrity and signal 
the AD flag for authoritative domains?. Views (it would lose the AA 
flag, then)?


What would be the best practice for dnssec verification? To use a fully 
validating local resolver? Any other choice? I am currently using a 
local "bind" as a resolver and it works fine for DNSSEC verification, 
except for my authoritative domains.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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

Records "not" too long fails with "ran out of space"

[Jesus Cea]

Configuring my RPZ installation, the zone fails to load because some 
register are "too long". The error in the logs is something like:


"""
dns_master_load: ../primarios/db.rpz.local:137146: ran out of space
"""

I did some tests and the zone load fails if records are longer than 243 
characters. According to RFCs, I understand that it should work for 
records up to 256 characters, with a maximum of 63-64 characters per label.


As I said, my zone fails to load if any domain in the RPZ is bigger than 
243 characters. Currently, my RPZ zone structure is something like:


"""
Z..X.com CNAME .
"""

This is bind 9.16.

I needed to delete some "long" records and I wonder why is my bind 
rejecting them.


--
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
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