Re: Insecurity proof failed

[Borja Marcos]

> On 12 Mar 2024, at 13:36, Mark Andrews  wrote:
> 
> Have you disabled EDNS to these servers in named.conf?  DNSSEC responses are 
> only returned
> if DO=1 is set in the request.  Named can learn that a server doesn’t support 
> EDNS if it doesn’t
> return EDNS responses consistently to EDNS requests.  If that happens named 
> will send plain DNS
> requests.

Gosh. YESSS!!

I had added those four DNS servers due to some nonsense with eset.com 
, the AV company. I will review that. 

I had to do that in the past because of authoritative servers that simply do 
not answer (some braindead firewall
involved, probably) to EDNS options or cookies. 


Thank you!




Borja.



signature.asc
Description: Message signed with OpenPGP
-- 
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

Insecurity proof failed

[Borja Marcos]

Hi,

This is driving me nuts. I have three BIND 9.18.24 running on FreeBSD. Two of 
them on FreeBSD 14, one on FreeBSD 13.2.

Just one of the servers is failing to resolve a single domain compared to the 
other two: checkpoint.com .

I get these errors:

<142>1 2024-03-12T11:36:21.957013+00:00 dnsanycast named 86604 - - insecurity 
proof failed resolving 'checkpoint.com/A/IN': 198.51.44.65#53
<142>1 2024-03-12T11:36:21.941389+00:00 dnsanycast named 86604 - - insecurity 
proof failed resolving 'checkpoint.com/A/IN': 198.51.45.1#53
<142>1 2024-03-12T11:36:21.924666+00:00 dnsanycast named 86604 - - insecurity 
proof failed resolving 'checkpoint.com/A/IN': 198.51.45.65#53
<142>1 2024-03-12T11:36:21.907492+00:00 dnsanycast named 86604 - - insecurity 
proof failed resolving 'checkpoint.com/A/IN': 198.51.44.1#53

and 
 these: validating checkpoint.com/A: got insecure response; parent indicates it 
should be secure

And ultimately my DNS servers returns a SERVFAIL.

The puzzling thing is, the other two servers work (this is a check on a 
different server from the same pool).

; <<>> DiG 9.18.24 <<>> @127.0.0.1 checkpoint.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40171
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: aa16c8ceb3a9eee9010065f0416206a44938e6d8f2b4 (good)
;; QUESTION SECTION:
;checkpoint.com. IN A

;; ANSWER SECTION:
checkpoint.com. 18 IN A 54.230.112.31
checkpoint.com. 18 IN A 54.230.112.106
checkpoint.com. 18 IN A 54.230.112.68
checkpoint.com. 18 IN A 54.230.112.55

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Mar 12 11:49:54 UTC 2024
;; MSG SIZE  rcvd: 135



I have the same configuration, using dnssec-validation set to auto.

Any clue on what might be failing? I am really lost!

Thanks,





Borja.




signature.asc
Description: Message signed with OpenPGP
-- 
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: Deprecated DSCP support

[Borja Marcos]

> On 29 Feb 2024, at 10:21, Petr Špaček  wrote:
> 
> On 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote:
>> I am working on a product in Nokia, and we currently use BIND provided by 
>> Rocky Linux 8 with security patches. Recently the requirement came that we 
>> should upgrade to at least 9.16. During the testing of this version we 
>> realized that a feature we used, DSCP, has stopped working. Reading about 
>> the topic, we found the article about it non-operational in 9.16, and 
>> removal in 9.18.
>>  We also saw the email on this mailing list, stating that "so far, nobody 
>> has noticed" it is missing. Well, we noticed it just now, and I would like 
>> to state that our product and most probably other telecom equipments using 
>> BIND would miss it greatly. As I read in that mail, there was an alternative 
>> plan which would re-implement this functionality. If it is feasible, please 
>> consider doing it. The alternative options, e.g. setting it via iptables 
>> cannot work in our use-case.
> 
> Could you please explain why it's not possible?
> 
> Maybe I'm naive, but something like
> 
> iptables -t mangle -A ... -p udp --dport 53 -j DSCP --set-dscp-class ...
> 
> seems like sensible approach to me, and actually in the right place of 
> networking stack.

Actually I’ve sometimes done the same on FreeBSD using its internal firewall 
facility. 

03000 setdscp cs7 ip from me to table(53)

But bear in mind that this is only guaranteed to work inside your network/ASN. 
It’s not unusual to scrub DSCP at the network border.





Borja.

-- 
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: monitoring BIND

[Borja Marcos]

> On 3 Aug 2023, at 17:07, sami.ra...@sofrecom.com wrote:
> 
>  Hello comunity
> please what is the most recommended tool for BIND monitoring and especially 
> display response time and latency thank you in advance.

For latency, your friend is Dnstap. The implementation on Bind is superb. When 
Dnstap reports a RESOLVER_RESPONSE event
it includes *both* the query timestamp and the received response timestamp. It 
doesn´t work on CLIENT_REPONSE right now,
although it may with a small caveat (I am going to lobby a bit: issue 3695).

Other DNS servers are not so complete so you should keep track of those 
timestamps yourself. 




Borja.

-- 
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 dns amplification attack

[Borja Marcos]

> On 28 Mar 2023, at 09:33, Nyamkhand Buluukhuu  wrote:
> 
> Hello,
> 
> We are having slowly increasing dns requests from our customer zones all 
> asking mXX.krebson.ru. I think this is a DNS amplification attack.
> And source zones/IP addresses are different but sending same requests like 
> below.

I wonder, maybe some of your customers have open recursive DNS servers 
themselves? Some brands of routers
are unfortunately easy to misconfigure.

I must play whack-a-mole now and then. 




Borja.


-- 
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: DF-Flag on UDP-based sockets?

[Borja Marcos]

> On 30 Nov 2022, at 08:20, Tom  wrote:
> 
> Hi list
> 
> Regarding ARM 9.18.9 
> (https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-edns-udp-size):
> "The named now sets the DON’T FRAGMENT flag on outgoing UDP packets."
> 
> Tested with BIND-9.18.9, I didn't saw any UDP packets, where the "DF"-flag 
> was set on the IP header (true for TCP, but never seen for UDP).
> 
> Which circumstands or which queries enforces BIND9 to set the "DF"-flag on 
> outgoing UDP-based packets?

I have checked on FreeBSD 13.1 and indeed I don’t see the flag. Neither for UDP 
queries or responses. 

What OS are you trying? Might be OS dependant. 





Borja.

-- 
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: Dnstap CLIENT_RESPONSE and query time information

[Borja Marcos]

> On 23 Nov 2022, at 10:09, Borja Marcos  wrote:
> 
> Hi,
> 
> I am working on some DNS monitoring using Dnstap. I have noticed that RR 
> messages include
> *both* the query time and response time but, despite being recommended on the 
> Protobuf
> specification (I know, it’s just a recommendation!) the CR messages do not 
> include it. 
> 
> Is there any particular reason for it? Looking at lib/dnstap.c, there is a 
> switch clause which
> especifically prevents Dnstap message types other than RR and FR from 
> obtaining
> a query time. 

I made a simple modification to dnstap.c (line 816, so that it allows CR 
messages to obtain
the query timestamp and it works, the query time (qtime) is already passed to 
dns_dt_send().

I have tried with 9.18.9 for now.


Cheers,



Borja.






-- 
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 CLIENT_RESPONSE and query time information

[Borja Marcos]

Hi,

I am working on some DNS monitoring using Dnstap. I have noticed that RR 
messages include
*both* the query time and response time but, despite being recommended on the 
Protobuf
specification (I know, it’s just a recommendation!) the CR messages do not 
include it. 

Is there any particular reason for it? Looking at lib/dnstap.c, there is a 
switch clause which
especifically prevents Dnstap message types other than RR and FR from obtaining
a query time. 

It would be really useful to have that information available. But I am not sure 
whether
there is any particular reason not to include it. Maybe avoiding an additional 
system call?


Thanks!




Borja.

-- 
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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Borja Marcos]

> On 21 Oct 2022, at 12:23, Ondřej Surý  wrote:
> 
> What you are really saying that we should dance how tech giants whistle, and 
> I don’t think succumbing to tech giants is a good strategy long term.

Not at all and I agree with you. 

But tell your customer that their email message didn’t arrive on time because 
the recipient has a misconfigured DNS server and
try to explain to them that, yes, Google resolved it successfully but you are 
working for the common good.


I know!





Borja.


-- 
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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Borja Marcos]

> On 21 Oct 2022, at 03:51, Mark Andrews  wrote:
> 
>> 
>> 
 Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be 
 able to find all EDNS0 incompatible servers and loosing customers to 
 8.8.8.8 - which is able to resolve these names..
>>> This is kind of moot argument - the DNS needs to evolve, and it can't 
>>> evolve if we keep supporting broken stuff. This needs to be fixed on the 
>>> authoritative operator side, not in BIND 9.
>> 
>> You're absolutely right. I guess I've just kind of given up on convincing 
>> other people the fix their stuff (dayjob trauma). Sorry about that.
> 
> It’s also a very small percentage of servers that are broken.  If you look at 
> the time series
> on https://ednscomp.isc.org/ you can drill done and see the values.  For 
> example there are a
> little over 10 servers for all zones in .GOV that exhibit this broken 
> behaviour.  It’s gone
> from ~11% in 2014 to 0.26% currently.  We are at the mop up stage.  For some 
> other populations
> we are at 0%.
> 
> The EDNS specification was updated in April 2013 to specify some unspecified 
> behaviour.  In
> particular this was added.

While I hearfully agree with the need to polish the network, some measures can 
be a problem unless there is a really big
commitment from the Big Guns.

In my case I had to abort an upgrade to 9.18 on our recursive servers because, 
well, “Google DNS worked better than ours”
going back to 9.16.

I know it´s the same situation that happened when Internet Explorer 
“successfully” rendered all kinds of abominations while proper web
clients barfed (with good reason!) and I also know that lousy formats and lack 
of respect for standars are the breeding
ground of serious security incidents.

End of rant: A wider consensus is needed.





Borja.


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

[Borja Marcos]

> On 13 Sep 2022, at 14:34, Peter  wrote:
> 
> Apparently, the first connect() happens (after chroot but) before
> droppings priviledges.
> (The FreeBSD integration script does set -u to UID "bind", by default.)
> 
> So, apparently, fstrm_capture should also run as UID "bind" (and would
> then need a proper filespace where it is allowed to create that
> socket). Or something else along that line.
> 
> The OP should check if their problem suddenly resolves when doing a
> "chmod 777" on that socket (and then devise a suitable design
> according to their security policy).

My fault indeed, sorry! *blush*.

Actually my confusion was slightly more stupid but still a permissions issue.

My apologies!




Borja.

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

[Borja Marcos]

Hi,


I am not sure this is intended behavior, or maybe I should file a bug.

I am doing some tests with dnstap and bind (9.18.6 now but I see the same 
behavior with older 9.18 versions). I am using
dnstap-go.

I have configured bind to use dnstap with no other options and using a Unix 
domain socket. (On named.conf, dnstap {all;};).

If I start named but the dnstap collector is not running it will never try to 
connect. I need to start the dnstap program 
_before_ starting named. 

>From the named.conf documentation I assumed that bind would retry the dnstap 
>connection periodically. (fstrm-reopen-interval).

Is that correct or I am making a wrong assumption? I think at least it would be 
desirable to have bind reconnect in case the dnstap
collector was restarted for whatever reason.

Versions:

bind 9.18.6
fstrm-0.6.1
protobuf-3.20.1,1
protobuf-c-1.4.0_3



Thanks!





Borja.


-- 
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 www.ecb.europa.eu tages ages

[Borja Marcos]

> On 20 Jun 2022, at 10:22, Borja Marcos  wrote:
> 

Looking at it there are also problem affecting the europa.eu domain.

Some servers are sometimes unresponsive over TCP (doing some simple queries
one of them took 5 seconds to answer).

And europa.eu fails to pass the 2020 DNS Flag Day tests.

https://ednscomp.isc.org/ednscomp/189248221d


Borja.


-- 
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 www.ecb.europa.eu tages ages

[Borja Marcos]

> On 17 Jun 2022, at 13:04, Matus UHLAR - fantomas  wrote:
> 
> Hello,
> 
> I encountered case where resolution of www.ecb.europa.eu takes long time and 
> I can't find out why.
> 
> I'm trying to find the culprit using dig +trace and resolution times change 
> from < 1 second to > 15 seconds, while response times reported by dig say 
> miliseconds.
> 
> multiple runs of dig seem to fix the issue until I clear named cache.
> (which indicated problem is in DNS, but I still have no idea where)
> 
> I'm out od ideas what to search for.

I tried this at home on my test recursive server (9.18.4) and I found this 
doing several rndc flush && dig www.ecb.europa.eu.

Whenever these timeouts hit the lame server log I saw resolution times greater 
than 3 s. By the way, the lame server reporting 
has greatly improved on 9.18 compared to the previous releases.

—
2022-06-20T09:56:34.356+02:00 source=elnuc 2022-06-20T07:56:34.356Z 
lame-servers: timed out resolving 'europa.eu/DNSKEY/IN': 147.67.12.4#53
2022-06-20T09:56:52.509+02:00 source=elnuc 2022-06-20T07:56:52.509Z 
lame-servers: timed out resolving 'europa.eu/DNSKEY/IN': 195.99.65.212#53
2022-06-20T10:00:47.834+02:00 source=elnuc 2022-06-20T08:00:47.834Z 
lame-servers: timed out resolving 'ecb.europa.eu/DS/IN': 195.99.65.212#53
2022-06-20T10:02:18.151+02:00 source=elnuc 2022-06-20T08:02:18.151Z 
lame-servers: timed out resolving 'europa.eu/DNSKEY/IN': 195.99.65.212#53
2022-06-20T10:02:19.414+02:00 source=elnuc 2022-06-20T08:02:19.413Z 
lame-servers: timed out resolving 'europa.eu/DNSKEY/IN': 54.154.94.36#53
2022-06-20T10:02:55.365+02:00 source=elnuc 2022-06-20T08:02:55.365Z 
lame-servers: timed out resolving 'europa.eu/DNSKEY/IN': 147.67.12.4#53
2022-06-20T10:09:14.025+02:00 source=elnuc 2022-06-20T08:09:14.025Z 
lame-servers: timed out resolving 'europa.eu/DNSKEY/IN': 195.99.65.212#53
2022-06-20T10:09:15.302+02:00 source=elnuc 2022-06-20T08:09:15.302Z 
lame-servers: timed out resolving 'europa.eu/DNSKEY/IN': 54.154.94.36#53
2022-06-20T10:09:55.377+02:00 source=elnuc 2022-06-20T08:09:55.377Z 
lame-servers: timed out resolving 'ecb.europa.eu/DS/IN': 54.154.94.36#53
2022-06-20T10:09:56.649+02:00 source=elnuc 2022-06-20T08:09:56.649Z 
lame-servers: timed out resolving 'ecb.europa.eu/DS/IN': 147.67.12.4#53
2022-06-20T10:14:57.756+02:00 source=elnuc 2022-06-20T08:14:57.756Z 
lame-servers: timed out resolving 'ecb.europa.eu/DS/IN': 147.67.250.4#53
2022-06-20T10:15:03.435+02:00 source=elnuc 2022-06-20T08:15:03.435Z 
lame-servers: timed out resolving 'ecb.europa.eu/DS/IN': 147.67.250.4#53
—

I blacklisted the four servers flagging them as “bogus” and my resolutions work 
now in less than 1 second right after flushing the cache.


42848   | 147.67.12.4  | EC-AS, LU
16509   | 54.154.94.36 | AMAZON-02, US
5400| 195.99.65.212| BT, GB
42848   | 147.67.250.4 | EC-AS, LU



—
server 147.67.12.4 {
bogus yes;
};

server 54.154.94.36 {
bogus yes;
};

server 195.99.65.212 {
bogus yes;
};

server 147.67.250.4 {
bogus yes;
};
—



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

Possible bug. Bind 9.18 blocking on dnstap

[Borja Marcos]

Hi,

I just stumbled upon a problem. It happened on FreeBSD 13.1-RC (going to update 
to 13.1 today).

I am running bind 9.18.3 with dnstap using a Unix socket. 

Once the socket has been opened by bind, if the process serving the Unix socket 
blocks and you try to 
kill named, it fails to stop, stays blocked on the dnstap socket until it is 
closed.


How to reproduce:

- I started bind 9.18.3

- Started dnstap, the Go program from https://github.com/dnstap/golang-dnstap. 
(dnstap -u /var/tmp…)

- I suspended the dnstap program (kill -STOP)

- Sent some queries to bind

- Tried to stop bind (either rndc stop or kill -TERM)

It won’t really exit unless I resume the dnstop process or I kill it.

Is it expected behavior? I am not sure there should be such a strong contract 
to deliver dnstap
messages to a blocked process. At least there should be a reasonable timeout 
maybe?

I haven’t opened a ticket because I am not sure it is considered a bug.


Cheers,






Borja.




-- 
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: Problems building bind 9.18.1 on FreeBSD

[Borja Marcos]

> On 25 Mar 2022, at 14:34, Ondřej Surý  wrote:
> 
>> On 25. 3. 2022, at 11:49, Borja Marcos  wrote:
>> 
>> Following up on this subject, looks like there were substantial changes to 
>> the build process for 9.18.1?
> 
> Yes.

Thanks. I was just wondering. 

> 
>> The port maintainers seem to be having a hard time with it.
> 
> There’s an issue tracker for any bugs found. Making general statements like 
> this is neither helpful
> to those “maintainers” (they can speak for themselves, do they) nor the the 
> upstream developers.

My apologies. I am not intending to be offensive of course!

I am just a spectator (I am using bind but I am not one of the maintainers nor 
I have time for that).

That said (and this is just an opinion) with all due respect of course, if bind 
evolves in a way that makes
it much harder to build on non Linux systems, I am concerned. 

Cheers,




Borja.


-- 
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: Problems building bind 9.18.1 on FreeBSD

[Borja Marcos]

Following up on this subject, looks like there were substantial changes to the 
build process for 9.18.1? The port maintainers
seem to be having a hard time with it.


Cheers,





Borja.

-- 
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: V 9.18.1 not listen on port 853 after rndc reload

[Borja Marcos]

> On 21 Mar 2022, at 14:51, MAYER Hans  wrote:
> 
> 
> Looking at the log I see: 
> network: error: creating TLS socket: permission denied
> 
> Why doesn’t named have the permissions after a „rndc reload“ but it has the 
> permissions after a start ? And why on one server but not on another ? 
> In both cases the daemon is running as user „bind“ with UID below 128 but not 
> as root. 

Because it usually starts as root and it demotes itself to “bind” whenever 
possible.

Maybe there is a mechanism in Linux to grant permission to a certain UID to 
bind() a socket to certain privileged 
port number, as it is used for NTP on FreeBSD?




Borja.

-- 
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: Problems building bind 9.18.1 on FreeBSD

[Borja Marcos]

> On 17 Mar 2022, at 10:41, Petr Špaček  wrote:
 *** Error code 2
>>> Interesting!
>>> 
>>> How do you build it?
>> Pretty straightforward.
>> ./configure with some options,
>> ./configure --disable-linux-caps --localstatedir=/var 
>> --sysconfdir=/usr/local/etc/namedb --with-dlopen=yes --with-libxml2 
>> --with-openssl=/usr --enable-dnsrps --with-readline=libedit --enable-dnstap 
>> --disable-fixed-rrset --disable-geoip --without-maxminddb --without-gssapi 
>> --with-libidn2=/usr/local --with-json-c --disable-largefile 
>> --with-lmdb=/usr/local --disable-querytrace --enable-tcp-fastopen 
>> --prefix=/usr/local --mandir=/usr/local/man --disable-silent-rules 
>> --infodir=/usr/local/share/info/  --build=amd64-portbld-freebsd13.0
>> make
>> I built 9.18.0 without any issues, it was as straightforward as it can be!
>> Make is the FreeBSD version, not GNU Make.
> 
> This is even more interesting. Can you retry with GNU Make to see if the 
> substitution will work?

Sure!

So “make” was making war instead of love. 

With GNU Make (latest version in ports) it compiled and Sphinx didn’t complain. 
And of course I ran configure after installing Sphinx.


Making all in man
gmake[3]: Entering directory '/usr/home/borjam/src/bind-9.18.1/doc/man'
echo ".. |rndc_conf| replace:: ``@sysconfdir@/rndc.conf``\n.. |rndc_key| 
replace:: ``@sysconfdir@/rndc.key``\n.. |named_conf| replace:: 
``@sysconfdir@/named.conf``\n.. |bind_keys| replace:: 
``@sysconfdir@/bind.keys``\n.. |named_pid| replace:: 
``@runstatedir@/named.pid``\n.. |session_key| replace:: 
``@runstatedir@/session.key``"
.. |rndc_conf| replace:: @sysconfdir@/rndc.conf\n.. |rndc_key| replace:: 
@sysconfdir@/rndc.key\n.. |named_conf| replace:: @sysconfdir@/named.conf\n.. 
|bind_keys| replace:: @sysconfdir@/bind.keys\n.. |named_pid| replace:: 
@runstatedir@/named.pid\n.. |session_key| replace:: @runstatedir@/session.key
/usr/local/bin/sphinx-build -b man -d ./_build/.doctrees/man -W -c . -a -n -D 
version="@""PACKAGE_VERSION@" -D today="@""RELEASE_DATE@" -D 
release="@""PACKAGE_VERSION@" -D rst_epilog="$(printf "${man_RST_EPILOG}")"  . 
./_build/man
Running Sphinx v4.3.1
making output directory... done
building [mo]: all of 0 po files
building [man]: all source files
updating environment: [new config] 34 added, 0 changed, 0 removed
reading sources... [100%] tsig-keygen   
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
writing... arpaname.1 { } ddns-confgen.8 { } delv.1 { } dig.1 { } dnssec-cds.1 
{ } dnssec-dsfromkey.1 { } dnssec-importkey.1 { } dnssec-keyfromlabel.1 { } 
dnssec-keygen.1 { } dnssec-revoke.1 { } dnssec-settime.1 { } dnssec-signzone.1 
{ } dnssec-verify.1 { } dnstap-read.1 { } filter-.8 { } filter-a.8 { } 
host.1 { } mdig.1 { } named-checkconf.1 { } named-checkzone.1 { } 
named-compilezone.1 { } named-journalprint.1 { } named-nzd2nzf.1 { } 
named-rrchecker.1 { } named.conf.5 { } named.8 { } nsec3hash.1 { } nslookup.1 { 
} nsupdate.1 { } rndc-confgen.8 { } rndc.conf.5 { } rndc.8 { } tsig-keygen.8 { 
} done
build succeeded.

The manual pages are in _build/man.



---

And for comparison this is what happened with FreeBSD stock make.



Making all in man
echo ""

/usr/local/bin/sphinx-build -b man -d ./_build/.doctrees/man -W 
 -c .-a  -n 
 -D version="@""PACKAGE_VERSION@"-D today="@""RELEASE_DATE@"
 -D release="@""PACKAGE_VERSION@"-D rst_epilog="$(printf 
"${man_RST_EPILOG}")"   . ./_build/man
Running Sphinx v4.3.1
making output directory... done
building [mo]: all of 0 po files
building [man]: all source files
updating environment: [new config] 34 added, 0 changed, 0 removed
reading sources... [100%] tsig-keygen   

Warning, treated as error:
../../bin/delv/delv.rst:99:Undefined substitution referenced: "bind_keys".
*** Error code 2

Stop.
make[3]: stopped in /usr/home/borjam/src/bind-9.18.1/doc/man
*** Error code 1

Stop.
make[2]: stopped in /usr/home/borjam/src/bind-9.18.1/doc
*** Error code 1

Stop.
make[1]: stopped in /usr/home/borjam/src/bind-9.18.1
*** Error code 1

Stop.
make: stopped in /usr/home/borjam/src/bind-9.18.1








Cheers,




Borja.






-- 
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: Problems building bind 9.18.1 on FreeBSD

[Borja Marcos]

> On 17 Mar 2022, at 08:59, Petr Špaček  wrote:
> 
> Hello,
> 
> On 17. 03. 22 8:49, Borja Marcos wrote:
>> Trying to compile bind 9.18.1 on FreeBSD I am stumbling upon a really silly 
>> problem. Getting plenty of errors like this
>> building the man pages.
>> building [man]: all source files
>> updating environment: [new config] 34 added, 0 changed, 0 removed
>> reading sources... [100%] tsig-keygen
>> Warning, treated as error:
>> ../../bin/named/named.conf.rst:901:Undefined substitution referenced: 
>> "named_conf".
>> *** Error code 2
> 
> Interesting!
> 
> How do you build it?

Pretty straightforward.

./configure with some options,
./configure --disable-linux-caps --localstatedir=/var 
--sysconfdir=/usr/local/etc/namedb --with-dlopen=yes --with-libxml2 
--with-openssl=/usr --enable-dnsrps --with-readline=libedit --enable-dnstap 
--disable-fixed-rrset --disable-geoip --without-maxminddb --without-gssapi 
--with-libidn2=/usr/local --with-json-c --disable-largefile 
--with-lmdb=/usr/local --disable-querytrace --enable-tcp-fastopen 
--prefix=/usr/local --mandir=/usr/local/man --disable-silent-rules 
--infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd13.0



make 

I built 9.18.0 without any issues, it was as straightforward as it can be!

Make is the FreeBSD version, not GNU Make.


> Please provide exact sequence of commands along with Sphinx and make version 
> information.

I had Sphinx sphinx-3.5.2_1,1 built with Python 3.7.12

I deleted Python 3.7 and Sphinx, rebuilt with Python 3.8.12, Sphinx version 
4.3.1, same result.


> 
>> I wonder whether I am missing some needed package. Also, is it really 
>> necessary to complicate the generation of man pages to
>> this extent?
> 
> Depends on who you ask. There are people who like to have correct path names 
> in the the man pages, and other group of people don't that much :shrug:.

I understand it is important to have proper documentation. But I wonder whether 
things have gone out of control with dependencies. Especially for such an 
important
piece of software as Bind 9. But there are plenty of simple ways to achieve 
that substitution.

Per Ondřej Surý’s suggestion (I didn’t know you can avoid using Sphinx) I have 
removed Sphinx, with was installed as a dependency from another port,
and now it builds perfectly.  THANK YOU!

Anyway, with all due respect I would suggest to examine dependencies carefully. 
Such an important package should keep dependencies to the really mandatory ones.
Or documentation should state somewhere that you don’t need Sphinx, _or_ there 
should be a configure option to ignore it.

Cheers,





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

Problems building bind 9.18.1 on FreeBSD

[Borja Marcos]

Hi

Trying to compile bind 9.18.1 on FreeBSD I am stumbling upon a really silly 
problem. Getting plenty of errors like this 
building the man pages.

building [man]: all source files
updating environment: [new config] 34 added, 0 changed, 0 removed
reading sources... [100%] tsig-keygen   

Warning, treated as error:
../../bin/named/named.conf.rst:901:Undefined substitution referenced: 
"named_conf".
*** Error code 2



I wonder whether I am missing some needed package. Also, is it really necessary 
to complicate the generation of man pages to
this extent?



Borja.


-- 
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: ipv6 adoption

[Borja Marcos]

> On 16 Feb 2022, at 16:50, Grant Taylor via bind-users 
>  wrote:
> 
> On 2/16/22 7:35 AM, Mark Tinka wrote:
>> I was assuming Linux has something similar, where in userland, you have the 
>> option to install which train of BIND you want, regardless of OS version.
> 
> Most of the -- what I'll call -- binary distributions of Linux tend to have a 
> fairly small range of any given versions of software in the repositories 
> provided by the Linux distribution provider.
> 
> There is nothing that prevents you from sourcing other versions, binary or 
> compile it yourself, from other providers.  But some people are unwilling to 
> accept the risk.

Well, (shameless plug) that’s the great thing about FreeBSD Ports. Moreover, 
many packages have important compile time options. What did the 
packager decide to omit for whatever reasons?

For software in which knowing what you are running is critical (such as bind) 
it’s a no brainer.




Borja.

-- 
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 'max-cache-size' Value on FreeBSD-13.0

[Borja Marcos]

> On 16 Feb 2022, at 10:53, Mark Tinka  wrote:
> 
> Hi all.
> 
> Just coming back to this... 
> 
> I notice that the release notes for 9.16.25 say the memory leak issue on 
> FreeBSD is now fixed:
> 
> *
> 
> On FreeBSD, TCP connections leaked a small amount of heap memory, leading to 
> an eventual out-of-memory problem. This has been fixed in:
> 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3051


> 
> *
> 
> If anyone was running/testing this train prior to this update on FreeBSD as a 
> resolver, have you seen the problem go away?
> 
> I know Borja was testing, but haven't heard from him in a while :-).

I’m here ;)

> We are still happily running 9.11.36 on our busiest resolvers, with no issue. 

Now I have 9.11.36, 9.16.24 and 9.18.0

What I have noticed with 9.18.0, which is running on the heaviest loaded 
server, is less memory footprint.

I started it on Monday and according to top it’s taking 486 MB (SIZE) - 375 MB 
(RES). And the memory pressure
is much less.

It’a working fine but in ISCs tradition of squeezing bad practices it will give 
you errors for misconfigured domains. I have had to
add some “server” clauses disabling cookies and all that.

I am updating the server running 9.16.24 to .25. Let’s see how it goes.

Running 9.16.24 it takes 1462 MB (size) - 1233 MB (res). I restarted named on 
17th January.

The load is not exactly the same. They are both part of an anyast pool, but one 
of them gets more email server requests while the
other one receives mostly customer queries.







Borja.

-- 
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: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?

[Borja Marcos]

> On 9 Jan 2022, at 13:11, Jason Vas Dias  wrote:
> 
> Thanks to all who responded !
> Yes, removing my Forwarders list did the trick .
> Never trust an ISP's DNS servers!

I’m late to the party, but anyway several issues are worth pointing out.

- First, there is no Hidden Google Internet, but Google is lousier than others 
when resolving DNS names. 
Their public DNS service does tolerate some misconfigurations. So you can find 
that they resolve names
that fail on other servers. And it’s not necessarily that your ISP servers are 
broken. Maybe they are more strict.

Microsoft has played this game for years with disastrous security consequences, 
like ignoring MIME types and guessing
file types.

In my opinion Google is misbehaving. They are playing the “I am better than 
others” card in the same way as Microsoft did.



- Second: Bind is getting stricter, tolerating less DNS configuration flaws 
than before.

That can result in failed queries. An example: 

$ dig aes.orange.es TYPE65 @your.bind.ip.address

$ dig the same @8.8.8.8

It is a good idea to check your domains using the DNS Flag Day checkers. 

And a good reference to test for DNS misconfiguration is DNSVIZ, which is not 
only useful to check DNSSEC records. It
is extremely picky about DNS records consistency.

For example, if you check healthservice.ie on DNSVIZ you will see this result:

https://dnsviz.net/d/healthservice.ie/dnssec/

With two warnings:

• ie to healthservice.ie: The following NS name(s) were found in the 
authoritative NS RRset, but not in the delegation NS RRset (i.e., in the ie 
zone): ns1.ie.topsec.com, ns2.ie.topsec.com, ns4.eu.topsec.com, 
ns3.ca.topsec.com
• ie to healthservice.ie: The following NS name(s) were found in the 
delegation NS RRset (i.e., in the ie zone), but not in the authoritative NS 
RRset: ns3.ca.topsectechnology.net, ns4.eu.topsectechnology.net, 
ns1.ie.topsectechnology.net, 
ns2.ie.topsectechnology.net


I would say it is a lousy configuration.

Cheers,





Borja.



___
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

Re: Nice new logging feature

[Borja Marcos]

> On 20 Dec 2021, at 17:56, Reindl Harald  wrote:
> 
> 
> 
> Am 20.12.21 um 17:53 schrieb Petr Menšík:
>> sure I confused that. I read it wrong way and thought they are present
>> on *BSD but not on Fedora. I know some messages are removed in Fedora
>> builds. I apologize for a confusion. Nobody complained on Fedora builds,
>> that is a good message to me.
> 
> OP was "I am trying 9.17 at home and I just noticed a very useful new 
> lame-servers log message: 2021-12-16T08:08:20.505Z lame-servers: timed out 
> resolving ’stupiddomain.com/ANY/IN': X.Y.Z.T#53. I haven’t seen this on 9.16"
> 
> i looked at my Fedora lame-log and answered with "exists in 9.16 here and i 
> doubt Fedora has backports for this"

Old thread, I know.

The differente is just that 9.16 doesn´t log timeouts in the lame-server 
category. All of the rest do work, like
unreachable or connection refused.

9.17 does log timeouts which is very useful. 






Borja.


___
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

Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?

[Borja Marcos]

> On 30 Dec 2021, at 09:07, Danilo Godec via bind-users 
>  wrote:
> 
> The source is a security audit report, claiming that using a single server 
> for both authoritative (for public use) and recursive (limited to internal 
> clients by means of 'allow-recursion' directive) roles increases the risk of 
> DoS attacks and DNS cache poisoning... They mentioned CVE-2021-20322 that 
> supposedly makes cache poisoning feasible (again) - that made them increase 
> the concern level to a 'medium'.
> 
> 
> While I understand how and why DoS and cache poisoning are bad, I don't 
> understand how separating these two roles would help mitigate the risk.

Well, it’s certainly best practice to separate the roles.

First and foremost: If you separate the roles it is much simpler to implement 
an effective access control. You can
completely disable requests to a recursive DNS server using traffic filtering. 
If you implement both network filtering and BIND access
lists an exploitation would require two mechanisms to fail/be buggy.

Assuming that you are using dual role servers, imagine that a bug that allows 
cache poisoning by crafting requests in some way is discovered. If you
are separating roles exploitation will be harder/less likely. 

Note that traffic filtering to a recursive DNS server is trickier than it 
seems. You also need to filter out spoofed requests at the network edge
or it would be possible to use your own DNS server(s) to launch DoS attacks 
against your own users.

Cheers,




Borja.

___
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

Re: Nice new logging feature

[Borja Marcos]

> On 16 Dec 2021, at 14:55, Reindl Harald  wrote:
> 
> 
> 
> Am 16.12.21 um 14:49 schrieb Borja Marcos:
>>> 
>>> bind-9.16.23-1.fc34.x86_64
>>> 
>>> 16-Dec-2021 13:08:10.598 lame-servers: connection refused resolving 
>>> 'ns2.serverion.eu/A/IN': 94.228.210.122#53
>>> 16-Dec-2021 13:11:29.269 lame-servers: host unreachable resolving 
>>> '250.84.141.45.in-addr.arpa/PTR/IN': 45.79.19.196#53
>>> 16-Dec-2021 13:11:31.804 lame-servers: host unreachable resolving 
>>> '250.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
>>> 16-Dec-2021 13:12:10.567 lame-servers: host unreachable resolving 
>>> '166.84.141.45.in-addr.arpa/PTR/IN': 198.58.118.167#53
>>> 16-Dec-2021 13:12:13.903 lame-servers: host unreachable resolving 
>>> '166.84.141.45.in-addr.arpa/PTR/IN': 45.33.18.44#53
>>> 16-Dec-2021 13:12:14.034 lame-servers: host unreachable resolving 
>>> '166.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
>>> 16-Dec-2021 13:12:15.773 lame-servers: host unreachable resolving 
>>> '166.84.141.45.in-addr.arpa/PTR/IN': 45.33.23.183#53
>>> 16-Dec-2021 13:12:15.938 lame-servers: host unreachable resolving 
>>> '166.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
>> Not for me definitely, but I am not running Linux. This is a FreeBSD port of 
>> the ISC release.
>> Does that version include some back ported code from bind 9.17?
> 
> i doubt that Fedora does any functional patching, maybe some of the build 
> flags while i'm not sure if the stuff shown at startup is really all

Hmm. Doesn’t look like that, I have compared the build options and it doesn’t 
explain it.

Thanks!




Borja.


___
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

Re: Nice new logging feature

[Borja Marcos]

> On 16 Dec 2021, at 13:15, Reindl Harald  wrote:
> 
> 
> 
> Am 16.12.21 um 10:02 schrieb Borja Marcos:
>> Hi,
>> I am trying 9.17 at home and I just noticed a very useful new lame-servers 
>> log message:
>> 2021-12-16T08:08:20.505Z lame-servers: timed out resolving 
>> ’stupiddomain.com/ANY/IN': X.Y.Z.T#53
>> I haven’t seen this on 9.16. Are there any plans to include it? 
> 
> bind-9.16.23-1.fc34.x86_64
> 
> 16-Dec-2021 13:08:10.598 lame-servers: connection refused resolving 
> 'ns2.serverion.eu/A/IN': 94.228.210.122#53
> 16-Dec-2021 13:11:29.269 lame-servers: host unreachable resolving 
> '250.84.141.45.in-addr.arpa/PTR/IN': 45.79.19.196#53
> 16-Dec-2021 13:11:31.804 lame-servers: host unreachable resolving 
> '250.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
> 16-Dec-2021 13:12:10.567 lame-servers: host unreachable resolving 
> '166.84.141.45.in-addr.arpa/PTR/IN': 198.58.118.167#53
> 16-Dec-2021 13:12:13.903 lame-servers: host unreachable resolving 
> '166.84.141.45.in-addr.arpa/PTR/IN': 45.33.18.44#53
> 16-Dec-2021 13:12:14.034 lame-servers: host unreachable resolving 
> '166.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
> 16-Dec-2021 13:12:15.773 lame-servers: host unreachable resolving 
> '166.84.141.45.in-addr.arpa/PTR/IN': 45.33.23.183#53
> 16-Dec-2021 13:12:15.938 lame-servers: host unreachable resolving 
> '166.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53

Not for me definitely, but I am not running Linux. This is a FreeBSD port of 
the ISC release. 

Does that version include some back ported code from bind 9.17?





Borja.

___
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

Re: Nice new logging feature

[Borja Marcos]

> On 16 Dec 2021, at 10:02, Borja Marcos  wrote:
> 
> 
> Hi,
> 
> I am trying 9.17 at home and I just noticed a very useful new lame-servers 
> log message:
> 
> 2021-12-16T08:08:20.505Z lame-servers: timed out resolving 
> ’stupiddomain.com/ANY/IN': X.Y.Z.T#53
> 
> I haven’t seen this on 9.16. Are there any plans to include it? It would 
> _really_ be useful. Our setup now includes
> 9.11 and 9.16 and soon I will have to switch to 9.16 and 9.18. 

Let me elaborate a bit, it is really useful to have a description of what 
triggered a SERVFAIL (a FORMERR, timeout, etc)
_and_ the IP address of the authoritative server involved.

I have been missing this!




Borja.

___
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

Nice new logging feature

[Borja Marcos]

Hi,

I am trying 9.17 at home and I just noticed a very useful new lame-servers log 
message:

2021-12-16T08:08:20.505Z lame-servers: timed out resolving 
’stupiddomain.com/ANY/IN': X.Y.Z.T#53

I haven’t seen this on 9.16. Are there any plans to include it? It would 
_really_ be useful. Our setup now includes
9.11 and 9.16 and soon I will have to switch to 9.16 and 9.18. 




Cheers,





Borja.




___
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

Re: Stale cache feature problems

[Borja Marcos]

> On 11 Nov 2021, at 10:40, Blažej Krajňák  wrote:
> 
> Hi,
> 
> št 11. 11. 2021 o 10:28 Borja Marcos  napísal(a):
>> First problem: I experienced random SERVFAILS with no apparent reason while 
>> i had the feature turned on. I think it
>> especially affected CDNs with multiple chained CNAMES and complex DNS server 
>> infrastructures.
>> 
> 
> glad to hear the confirmation of this problem. I experienced the same
> behaviour in our ISP network. Issue  #2982
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2982
> 
> Please, add your conditions and findings to ticket.

I will.

I’ll add what I have for now, but it’s just anecdotal evidence.

I can try to get more debugging information including packet captures. I 
imagine it has something
to do with an interaction between CDNs (short TTL A records for DNS servers) 
and making the
wrong decision to use stale records.

It won’t be much of a hassle at home. As it is affecting mostly the Ubiquiti 
access points I can arrange
for them to use the misbehaving bind, and the rest of the network to use 
different servers.





Borja.


___
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

Stale cache feature problems

[Borja Marcos]

Hi,

I’ve been trying the stale answers feature out of curiosity (seems to be a 
useful idea) but I have ran into problems.

I tried at home, so nobody was actually hurt!

I am running BIND 9.16.22 built from ports on FreeBSD 13-STABLE and I didn’t 
attempt any tuning,  I just enabled
stale-answer-enable yes;

First problem: I experienced random SERVFAILS with no apparent reason while i 
had the feature turned on. I think it 
especially affected CDNs with multiple chained CNAMES and complex DNS server 
infrastructures. 

As far as I know I have good connectivity, both IPv4 and IPv6.

The queries that failed a lot were:

doh.xfinity.com A and 
ping.ui.com A and 
gs.loc.apple.com A and 
nv2-namain-deco.netatmo.net A and 


The errors started when I enabled the feature, and they completely went away 
when I disabled it days later (I feed the
querylog and errors into Graylog)

Second problem: There is a bug. If I comment out the stale-answer-enable line 
on named.conf and I issue a “rndc
reconfig” the feature does not get turned off. It stays on until I restart the 
daemon.



Cheers,





Borja.



___
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

Re: BIND 'max-cache-size' Value on FreeBSD-13.0

[Borja Marcos]

> On 13 Sep 2021, at 09:40, Ondřej Surý  wrote:
> 
> Hi,
> 
> if you have reliable reproducer, please fill an issue at 
> https://gitlab.isc.org/isc-projects/bind9/-/issues
> 
> While this mailing list is monitored by the BIND 9 team, it’s more practical 
> to have an issue filled by
> a person experiencing the problem where we can interact directly and ask 
> additional questions.
> Scraping the information from the mailing list chatter is very impractical.

Thanks, I understand.

Right now I don’t have anything solid. As I said, I have not experienced Mark’s 
serious issue. But trying
to assign a bogus address to an unnumbered interface I wasn’t using *seems* to 
reduce the growth in
memory footprint. 

I said *seems*, so again nothing solid. 

If I can I will set up a spare non production server and run a stress test with 
OARC’s tools and some sample
data sets. In that case make sure I will report what I find.




Borja.

___
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

Re: BIND 'max-cache-size' Value on FreeBSD-13.0

[Borja Marcos]

> On 10 Sep 2021, at 13:30, Mark Tinka  wrote:
> 
> 
> 
> On 9/10/21 12:35, sth...@nethelp.no wrote:
> 
>> Freebsd 12.2-STABLE here with servers running BIND 9.16.15, 9.16.18
>> and 9.16.20, all using libuv 1.41.0, all installed from ports. Typical
>> query load from around 3k qps to around 14k qps. No sign of any memory
>> leak.
> 
> Would be interesting to hear your experiences when/if you do move to 
> FreeBSD-13.0.
> 
> Still going nice and stable with 9.11.

I haven’t noticed any of that, although the memory footprint seems to be lower 
after doing a couple of things.

1- Updating libuv to 1.42 on one of the servers

2- Adding a bogus 127.10.whatever to the spare Ethernet interface I am not 
using, per a previous comment on
this thread about a memory leak due to interfaces with no addresses.

So now I have two recursives running FreeBSD 13, one with libuv 1.41, the other 
one with 1.42. The behavior
seems to be similar, I had a slow growing memory usage when there was no IP 
address assigned to the spare, unused
Ethernet interface (even though I didn’t put a listen-on { any; }; clause.




Borja.


___
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

Re: BIND 'max-cache-size' Value on FreeBSD-13.0

[Borja Marcos]

> On 9 Sep 2021, at 06:59, Mark Tinka  wrote:
> 
> 2.5 days in, and 9.11 is still running good, with no crashing.
> 
> Safe to say that this memory leak is definitely an issue with 9.16.

Which version of libuv are you using? I am running 1.41 and the latest is 1.42.

I haven’t seen that behavior and my recursives handle about 100,000 requests 
per minute.

Just in case I have updated libuv on one of them.

Also, did you install bind 9.16 from ports or from a package? From ports, which 
options
did you enable?

Cheers,




Borja.

___
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

Re: Preventing a particular type of nameserver abuse

[Borja Marcos]

> On 13 Apr 2021, at 11:31, Julien Salort  wrote:
> 
> Is there really a usefulness to reply with code 5, instead of silently 
> ignoring the request?

Yes, we do it.

imagine a customer who uses to connect from different locations (hence 
different ISPs) and for whatever
reason keeps a static list of resolvers in resolv.conf.

If the customer queries your DNS servers from a non authorized location and 
they ignore the request you
will force the resolver to time out. If, however, the query is refused, the 
resolver will send it to the next
server in the list.

Being short messages means they are useless for a DDoS. Anyway we keep an eye 
on it.





Borja.

___
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

Re: Logging on a Bind server

[Borja Marcos]

> On 20 Oct 2020, at 18:02, Chuck Aurora  wrote:
> 
> On 2020-10-20 10:34, Borja Marcos wrote:
>>> On 20 Oct 2020, at 17:28, Rick Dicaire  wrote:
>>> On Tue, Oct 20, 2020 at 10:17 AM  wrote:
>>> Dear BIND-Users,
>>> Does someone has an idea, which log I have to activate.
> 
> While everything Borja says below, and what Kevin said in the other
> subthread, is absolutely true, in this case I am not sure these are
> the best answers. :)
> 
> I would suggest to the OP that you go to your software vendor and ask
> exactly why you should be concerned about queries going to that
> particular server.  Demand detailed information, which should be a
> reasonable thing, given what your company is paying them.

Of course :) Anyway, gaining the capability of tracing a DNS query so that you
know which clients started it can be extremely valuable.




Borja.


___
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

Re: Logging on a Bind server

[Borja Marcos]

> On 20 Oct 2020, at 17:28, Rick Dicaire  wrote:
> 
> On Tue, Oct 20, 2020 at 10:17 AM  wrote:
> Dear BIND-Users,
> 
> Does someone has an idea, which log I have to activate.
> 
> 
> Do you have querylog enabled? 

Querylog is not enough. It will tell you which clients are sending which 
queries, but not which queries
go to the Server Of Interest. It won’t log the queries the recursive server 
sends itself.

That’s a good use case for dnstap. 

As a sort of desperate measure you can capture packets sent to the suspicious 
IP addresses (no need to
put the interface in promisc mode) and check which queries were sent to them. 






Borja.

___
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

Re: bind 9.16.7 Odd query error (Borja Marcos)

[Borja Marcos]

> On 1 Oct 2020, at 08:36, Mark Andrews  wrote:
>> According to the documentation the default values for fetches-per-zone and 
>> fetches-per-server are zero,
>> which means there is no limit. 
> 
> Sorry, shouldn’t answer when on a phone.  See max-recursion-queries

Thanks, yes, I found it while you wrote the answer. Telepathy!

That said, is that default value too low in the DNSSEC era? A DNS query 
nowadays looks like
a particle collision in an accelerator. 

I have raised it to 200. Too high for sure but nobody should get hurt.

Thank you very much,




Borja.

___
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

Re: bind 9.16.7 Odd query error (Borja Marcos)

[Borja Marcos]

> On 30 Sep 2020, at 22:34, Mark Andrews  wrote:
> 
> No, it’s just fetches per query taking effect.  With a empty cache there are 
> just too many queries made looking up addresses of name servers. You can 
> raise the default slightly. 

Alright, I think I found this particular issue. I begun hammering quotas and 
this one is the culprit in this particular case:

max-recursion-queries

which, according to the documentation, has a default value of 75. I raised it 
to 200 
(I said, hammering!) and now it works reliably.

Maybe the default value is too low.






Borja.

___
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

Re: bind 9.16.7 Odd query error (Borja Marcos)

[Borja Marcos]

> On 30 Sep 2020, at 22:34, Mark Andrews  wrote:
> 
> No, it’s just fetches per query taking effect.  With a empty cache there are 
> just too many queries made looking up addresses of name servers. You can 
> raise the default slightly. 


According to the documentation the default values for fetches-per-zone and 
fetches-per-server are zero,
which means there is no limit. 

What am I missing? 

Thanks!




Borja.

___
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

Re: bind 9.16.7 Odd query error (Borja Marcos)

[Borja Marcos]

> On 30 Sep 2020, at 15:29, Bob McDonald  wrote:
> 
> Same thing here. Here's what I found.
> 
> 1) there's and old version of the root hints file. Nov 2017. Current is sept 
> 2020. New one didn't change things. I'll look at my other setup which slaves 
> the root.
>Caveat: I'm running FreeBSD 12.1
> 2) Upon executing the dig a second time, it resolves.
> 
> Almost looks like some sort of priming issue.

Phew, not alone. I thought something similar, I see the same problem either 
“secondarying" the root zone
or using a root.hints file.

Curiously it works perfectly when I disable IPv6. I can get a packet trace but 
with all the DNSSEC stuff it
gets crazy to check.

I was wondering, what kind of errors can fall into that “default/unspecified” 
error cathegory?

A race condition in the cache?





Borja.



___
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

bind 9.16.7 Odd query error

[Borja Marcos]

Hello,

I have an odd problem running bind at home. Shortly after flushing the cache I 
get a SRVFAIL
asking for 8.8.8.8.in-addr.arpa. PTR

; <<>> DiG 9.14.8 <<>> 8.8.8.8.in-addr.arpa. PTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2731
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 487f9d958627753d01005f7335b3f026bc7b8f6d5a24 (good)
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.  IN  PTR


After compiling bind with trace enabled and setting up a debug channel I can 
only see these errors:

<179>1 2020-09-29T15:25:07.992319+02:00 elnuc named 96467 - - query 
client=0x80659c968 thread=0x800f4de00 (8.8.8.8.in-addr.arpa/PTR): 
query_gotanswer: unexpected error: failure

client @0x80659c968 192.168.1.205#62912 (8.8.8.8.in-addr.arpa): query failed 
(failure) for 8.8.8.8.in-addr.arpa/IN/PTR at query.c:6922



No clue about the cause of this.

The server is using both IPv4 and IPv6 and it works if I disable IPv6. As far 
as I know I have no IPv6 connectivity problems.

Any ideas about that “unexpected error: failure”? After several seconds the 
query works.



Thanks!






Borja.

___
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

Re: bind 9.16.6 on FreeBSD - Assert

[Borja Marcos]

> On 3 Sep 2020, at 11:13, Ingeborg Hellemo  wrote:
> The server is dualstack and serves DNS via both IPv4 and IPv6.
> 
> Has anyone observed something similar?

 No, I haven’t seen this one.

If you have used the ports subsystem, can you recompile the port with the 
WITH_DEBUG option? 
Doing that the backtrace will include the function names.


Best regards,





Borja.


___
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

Re: bind 9.16.6 on FreeBSD - Assert

[Borja Marcos]

> On 2 Sep 2020, at 09:15, Søren Andersen  wrote:
> 
> It looks like the same bug to me. - Did you try to patch your source code 
> with the path isc just made?

No, I am not aware of a patch. I have rolled it back to 9.11 for now, it’s a 
production server.


Thanks,




Borja.

___
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

Re: bind 9.16.6 on FreeBSD - Assert

[Borja Marcos]

> On 1 Sep 2020, at 19:48, Søren Andersen  wrote:
> 
> hmm.. I think you hit this bug right here: 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2104

Looks like that. I compiled bind with debug symbols and it crashed again.

No way to append this to your bug report, it’s closed.




Borja.


——
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - rbt.c:2355:
 REQUIRE(newbits <= rbt->maxhashbits) failed, back trace
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #0 0x43fe19
 in assertion_failed()+0x59
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #1 0x7ba3d8
 in isc_assertion_failed()+0x38
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #2 0x5cbb8f
 in rehash()+0x9f
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #3 0x5c2dc7
 in maybe_rehash()+0x47
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #4 0x5c5574
 in hash_node()+0xd4
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #5 0x5c5089 in 
dns_rbt_addnode()+0xf19
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #6 0x5e6bd0 in 
findnodeintree()+0x260
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #7 0x5d1c60 in 
findnode()+0xa0
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #8 0x5201a0 in 
dns_db_findnode()+0x130
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #9 0x6a8351 in 
cache_name()+0x3a1
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #10 0x6a240f in 
cache_message()+0x16f
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #11 0x69f4a6 in 
resquery_response()+0xd06
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #12 0x804d03 in 
dispatch()+0xc63
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #13 0x800751 in 
run()+0x41
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #14 0x80245e036 in 
_fini()+0x801c3a35e
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - exiting (due to 
assertion failure)
<6>1 2020-09-02T04:30:04.407121+00:00 host1 kernel - - - pid 49310 (named), jid 
0, uid 53: exited on signal 6
——

___
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

bind 9.16.6 on FreeBSD - Assert

[Borja Marcos]

Hi,

I had a named process aborting with an assert. 

<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - rbt.c:2355: 
REQUIRE(newbits <= rbt->maxhashbits) failed, back trace
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - #0 0x43d260 in ??
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - #1 0x62035a in ??
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - #2 0x514868 in ??
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - #3 0x515616 in ??
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - #4 0x529c7d in ??
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - #5 0x579df7 in ??
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - #6 0x645e1c in ??
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - #7 0x80225e036 in ??
<26>1 2020-08-27T15:52:04.00+00:00 host named 6520 - - exiting (due to 
assertion failure)
<6>1 2020-08-27T15:52:04.091803+00:00 host kernel - - - pid 6520 (named), jid 
0, uid 53: exited on signal 6

I have a full log of queries (it’s a recursive only server) and I haven’t seen 
anything unusual before the crash. Unfortunately the
program was stripped, I have recompiled it with debug symbols.

It is bind 9.16.6, built from ports on FreeBSD 11.3.

Any hint on what to look for? Fortunately I have another server running 9.11. 
It wasn’t affected.

Thanks!





Borja.


___
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

Re: A couple of regression problems between 9.11.7 and 9.14.2

[Borja Marcos]

> On 5 Jun 2019, at 14:56, Tony Finch  wrote:
> 
> Borja Marcos  wrote:
> rigol.com is related to DNS cookies as well as the DNS flag day, yes.
> 
> login.repsol.com is a lame delegation that is exposed by qname minimization.

Thanks, I missed the second one looking at packet captures. Guess I’m getting 
old. 

So 9.11 is more tolerant anyway. 





Borja.


___
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

A couple of regression problems between 9.11.7 and 9.14.2

[Borja Marcos]

Hi,

I’ve been trying bind 9.14.2 and I have noticed a couple of behavior 
differences between 9.11 and 9.14.

Problem 1:

I had a problem resolving the rigol.com domain. Looking at packet captures and 
comparing I saw that the
authoritative servers for rigol.com were ignoring packets with a cookie option.

On 9.14 the operation got stuck when sending a query to 140.205.81.61, 
140.205.81.62, 140.205.228.61 and
140.205.228.62.

My server was sending a query with a cookie, timing out after several retries 
and returning a SERVFAIL.
I tried to disable cookies and this time it worked. Looks like a misconfigured 
server is discarding DNS
queries with options it doesn’t understand. 

Disabling cookies on my server (send-cookie no) fixed it. Seems that the DNSSEC 
and EDNS option works.

With 9.11 the behavior is different. After several attemps without an answer it 
sends a query without EDNS options
that gets a reply.

Note that it’s not a simple case of rejecting queries with EDNS options. The 
offending name servers are
ignoring queries with the cookie option, not with “accept DNSSEC security RRs”. 
As long as the cookie is not
present they reply.

Anyway, 9.11 retries without options, 9.14 times out and returns a SERVFAIL. Is 
this intended?


Problem 2:

I also noticed that 9.14.2 is not resolving login.repsol.com A (returning 
SERVFAIL) while 9.11.7 does.

Seems to be a misconfiguration problem in some of the authoritative servers, 
yet 9.11 works and
9.14 SERVFAILs.

Is all of this part of a collective “DNS Flag Day”? ;) Or is it unintended?



Thanks!




Borja Marcos.


___
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