DoH credentials

[Julien Salort]

Hello,

I am trying bind9 DoH features (bind9 9.18.18). It works from Firefox, 
although it feels slower than with native resolver.


However, it seems that this makes an open resolver, i.e. there is no 
authentication of any sort.


I haven't found any reference to how to set up credentials in this doc:

 https://bind9.readthedocs.io/en/latest/reference.html#http-block-grammar

Because I am using an Apache proxy, bind9 sees the incoming requests as 
localhost, so allows all recursive requests from anybody.


Does it mean that credentials have to be implemented by the webserver ?

Firefox, for example, does not easily provide a way to specify credentials.

Also, strangely, the requests work fine from Firefox, or from curl 
--doh-url, but dig +https (version 9.18.25) says:


ALPN for HTTP/2 failed.
;; no servers could be reached

Cheers,


Julien

--
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: Moving to a IPv4 only server

[Julien Salort]

Le 18/08/2023 à 22:14, Ondřej Surý a écrit :


You did the classic mistake - assuming what the problem is and then trying to 
find a solution for that problem.

You should start with just describing what you see - and the logs you sent 
indicate that the named is unable to communicate on port 53. This indicates 
that your network (firewall on the server, firewall at the provider) might be 
blocking DNS queries to the outside world. You should diagnose that - try 
sending DNS queries to those addresses by hand and look what’s happening on the 
wire (tcpdump, wireshark, etc. are your friends).

Ondřej


You are right !

There was indeed a limitation on outbound traffic on port 53 in the network.

It is now working good.

Thanks,

Julien

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

Moving to a IPv4 only server

[Julien Salort]

Hello,

I am sorry if this is a FAQ. I haven't been able to find the answer.

I used to have bind9 running on a server with both IPv4 and IPv6. This 
server has failed unfortunately, and I am setting up replacement using 
the last backup of the failed server. The new server happens to have 
IPv4 address only, unfortunately. Both the old and the new server are 
running Ubuntu 22 if that matters.


I copied /etc/bind directory from the backup to the new server.

Authoritative zones work fine. It also transfers successfully to the 
slaves when I make changes in the zones.


However, I can't get the recursion to work. I originally had a lot of 
"network unreachable" with IPv6 addresses. So I figured I should start 
bind with -4 option. Now, I no longer have the "network unreachable" 
errors in the log, but it is still unable to recurse.


For example:

dig www.google.com @127.0.0.1

;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> www.google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35198
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 1988 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Aug 18 19:55:30 UTC 2023
;; MSG SIZE  rcvd: 71


And in the log file:

Aug 18 19:55:23 vpsl named[3183]: client @0x7f8a4c0152f8 127.0.0.1#33163 
(www.google.com): query: www.google.com IN A +E(0)K (127.0.0.1)
Aug 18 19:55:28 vpsl named[3183]: resolver priming query complete: timed 
out
Aug 18 19:55:28 vpsl named[3183]: client @0x7f8a5420b6f8 127.0.0.1#43890 
(www.google.com): query: www.google.com IN A +E(0)K (127.0.0.1)
Aug 18 19:55:30 vpsl named[3183]: shut down hung fetch while resolving 
'www.google.com/A'
Aug 18 19:55:30 vpsl named[3183]: client @0x7f8a54213b58 127.0.0.1#46373 
(www.google.com): query failed (operation canceled) for 
www.google.com/IN/A at query.c:7794
Aug 18 19:55:30 vpsl named[3183]: client @0x7f8a5420b6f8 127.0.0.1#43890 
(www.google.com): query failed (operation canceled) for 
www.google.com/IN/A at query.c:7794
Aug 18 19:55:30 vpsl named[3183]: client @0x7f8a4c0152f8 127.0.0.1#33163 
(www.google.com): query failed (operation canceled) for 
www.google.com/IN/A at query.c:7794
Aug 18 19:55:38 vpsl named[3183]: resolver priming query complete: timed 
out



It feels like there are some root server addresses with IPv6 address 
that it can't use, but I have no clue where these addresses are and how 
to replace them with their IPv4 counterparts.



Thanks for any clue,


Julien

--
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.18.0 and Mac OS X 10.15.7 - cannot build

[Julien Salort]

Le 22/02/2022 à 02:29, Larry Stone a écrit :


So, just for fun, I decided to see if I could build 9.18.0 on my current 
MacBookPro (where I already run 9.16.26). It’s on MacOS Catalina 10.15.7 
(cannot go higher - new MacBookPro coming soon!).


For information, bind 9.18.0 compiles fine under Macports on a variety 
of systems, including Catalina.


https://ports.macports.org/port/bind9/builds/

Julien

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

[Julien Salort]

Le 13/04/2021 à 00:55, Richard T.A. Neal a écrit :


That's exactly what I do - I have some code that's watching for a frequent occurrence of these 
sorts of queries and then adds a firewall rule for a predetermined amount of time to simply drop 
the incoming packets at the firewall - this prevents them from reaching BIND in the first place and 
thus consuming system resource on the BIND server. And I say "predetermined amount of 
time" because that rule is then removed after a period of time in case the abuse was 
"unintentional" (ahem), or in case it came from a system using a non-static IP (i.e. a 
different user may be using that IP now, so I don't want to block them).


Do you block specifically the dns queries in the firewall, or straight 
out block the IP?


Reading this thread, I considered simply enabling the fail2ban 
named-refused jail, but they advise against it because it would end up 
blocking the victim rather than the attacker.


I understand that always ignoring these request may be bad if it causes 
some timeout somewhere (though I still do not quite fully understand 
what legitimate requests those may be for a server which only does 
authoritative answers). Couldn't bind then have a built-in option to 
ignore repeated attempts from a given host, and cap the number of error 
codes sent to a given host per day?


Julien

___
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

[Julien Salort]

Le 13/04/2021 à 07:12, Ondřej Surý a écrit :

BIND 9.11 has minimal-any option that’s helpful to reduce the attack 
impact: https://www.isc.org/blogs/bind-release-911/ 



RRL should also help to limit the responses: 
https://kb.isc.org/docs/aa-01000 


Usually the source IP is spoofed, so blocking it might be causing 
collateral damage in case the target of the attack is a resolver, but 
again in general case fail2ban that parses named log files might be a 
good option to add a temporary ban on the ip. Just bear in mind you 
are not blocking the attacker, but the victim.


I also have a lot of these (sl) queries in my logs.

Would it not be possible to have an option to tell bind to refrain from 
answering to all unauthorized queries over UDP?


Is there really a usefulness to reply with code 5, instead of silently 
ignoring the request?


A built-in option would be much easier than to require every server to 
have a dedicated fancy firewall rule.


But I have no idea how much work it would be to add this feature in bind.


Cheers,


Julien

___
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: Timeout setting

[Julien Salort]

Le 25/03/2021 à 18:21, John W. Blue via bind-users a écrit :


When I queried the authoritative server directly it worked:

;; QUESTION SECTION:
;111.250.179.17.in-addr.arpa.   IN  PTR

;; ANSWER SECTION:
111.250.179.17.in-addr.arpa. 86400 IN   PTR rn2-msbadger07105.apple.com.

;; Query time: 62 msec
;; SERVER: 17.47.176.10#53(17.47.176.10)

I would recommend that you too do a dig @ and see what you get.

If it works then you can start examining your on prim configs .. if it does not 
work then you need to be using wireshark to figure out what is happening to the 
traffic.

Either way you need to first break your troubleshooting into two parts .. on 
prim vs off prim and proceed from there.


Thank you for your answer.

If I query either authoritative server with dig, or the local recursive 
server, it works in both cases (though I get 164 msec, instead of your 
62 msec, presumably because I am based in Europe; I guess 100 msec to 
cross the Atlantic ocean is not too bad):


;; QUESTION SECTION:
;111.250.179.17.in-addr.arpa.    IN    PTR

;; ANSWER SECTION:
111.250.179.17.in-addr.arpa. 86400 IN    PTR rn2-msbadger07105.apple.com.

;; Query time: 164 msec
;; SERVER: 17.47.176.10#53(17.47.176.10)


Besides, I have other messages from the same source that do get 
delivered. Even the particular message that was originally rejected, was 
eventually accepted when the relay tried again later.


I have not been able to reproduce the timed out result from command 
line. It seems to be a rare occurrence. I have also an example with 
messages from this list: I usually receive them, but three messages from 
today failed (they have actually been sent to my backup mx, so I still 
received them in the end).



Julien

___
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

Timeout setting

[Julien Salort]

Hello,


I have a VPS running postfix and bind9. Bind is used as a recursive 
resolver, in particular to be able to query anti-spam database.


Postfix is also configured to reject incoming connections from servers 
with no reverse dns.


It works great overall, but sometimes legitimate messages get rejected 
because the reverse dns query fails.


Here is an example (anonymized email and host address):

In mail.log:

450 4.7.1 Client host rejected: cannot find your reverse hostname, 
[17.179.250.111]; from= 
to= proto=ESMTP helo= 
(total: 1)


In named journal:

mars 02 01:14:20 example.com named[2756114]: client @0x7f3a0808c750 
127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: 
111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1)


mars 02 01:14:25 example.com named[2756114]: client @0x7f3a08079d00 
127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: 
111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1)


mars 02 01:14:32 example.com named[2756114]: client @0x7f3a0808c750 
127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query failed (timed out) 
for 111.250.179.17.in-addr.arpa/IN/PTR at query.c:6883


mars 02 01:14:32 example.com named[2756114]: client @0x7f3a000d5110 
127.0.0.1#49520 (insideapple.apple.com): query: insideapple.apple.com IN 
MX + (127.0.0.1)



So there is a timeout.

Now if I try again:

$ dig -x 17.179.250.111 @localhost +short
rn2-msbadger07105.apple.com.


So it seems that it is just that sometimes the query takes a bit longer...


Is there a general advice regarding timeout for bind?

Should I just choose a longer timeout? Or is there a reason for the 
default value?



I did not have such problems when I was using the ISP dns server instead 
of a local recursive resolver. So I was wondering if the configuration 
is sub-optimal somehow...



Thank you,


Cheers,


Julien


___
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