Re: Problem with a certain domain

[Paul Kosinski via bind-users]

Could you send the email from another account (which doesn't use your DNS 
server)? It's not too hard to set up a free account with services like Outlook, 
Yahoo or (if desperate) Gmail.


On Mon, 03 Jun 2024 18:46:40 +0200
Thomas Barth via bind-users  wrote:

> Hello,
> 
> I cannot send them an email to inform about a dns problem. The mail gets 
> stuck in the queue.
> 
> postqueue -p
> (Host or domain name not found. Name service error for name=mx.renr.es 
> type=A: Host not found, try again)
>   r...@mallorcazeitung.es
> 
> 
> Bind reports a communication error.
> 
> dig mx.renr.es
> ;; communications error to 127.0.0.1#53: timed out
> 
> I could enable the bind logging:
> 
> 03-Jun-2024 18:34:22.681 client @0x7f014c88ed68 127.0.0.1#54496 
> (mallorcazeitung.es): query: mallorcazeitung.es IN MX +E(0)K (127.0.0.1)
> 03-Jun-2024 18:34:36.098 client @0x7f014ef48168 127.0.0.1#59706 
> (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1)
> 03-Jun-2024 18:34:41.106 client @0x7f014dd71768 127.0.0.1#56423 
> (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1)
> 
> Should I perhaps ask the mail user to unsubscribe from this website due 
> to troubles of bad configuration?
-- 
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: 9.18 BIND not iterated over all authoritative nameservers

[Paul Stead]

I wasn't

On Sat, Oct 28, 2023, 5:23 PM Ondřej Surý  wrote:

> Please don’t use Postel’s Law as excuse for implementations that break
> standards: https://datatracker.ietf.org/doc/html/rfc9413
> --
> Ondřej Surý — ISC (He/Him)
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> On 28. 10. 2023, at 17:50, Paul Stead  wrote:
>
> 
> As a previous ISP admin I too have come across similar situations and
> frustrations.
>
> I can only say that Google and Cloudflare seem to follow Postel's Law
> moreso than BIND.
>
> I agree this perpetuates bad practices but end users aren't interested in
> technical reasoning, especially when "it works everywhere else, you must be
> broken"
>
> Paul
>
>
> On Sat, Oct 28, 2023, 3:56 PM Rick Frey  wrote:
>
>> As Mark mentions, the NS records gtm.bankeasy.com need to be corrected
>> and failure is not due to lack of iterating through all auth nameservers
>> (all of the auth nameservers have the bad NS record anyway).
>>
>> Not sure how many other domains you are running into similar problem, but
>> you could disable qname-minimization in 9.18 to mimic previous behavior of
>> 9.16 if that number is large.  I believe qname-minimization is a global
>> directive so it would remove privacy benefits of QNAME minimization for all
>> recursive queries from your nameserver.
>>
>> As DNS admin of another ISP, I sympathize dealing with failures caused by
>> non-compliant authoritative nameservers.  These non-compliant auth
>> nameservers can have little motivation to fix, especially when other large
>> ISPs or public resolvers (looking at you Google and Cloudflare) don’t
>> enforce DNS standards.   Many non-compliant nameservers/records would be
>> cleaned up if public/centralized DNS providers such as Google/Cloudflare
>> would enforce since it would inflict those failures on a much larger user
>> base.
>>
>>  - Rick
>>
>>
>>
>> On Oct 27, 2023, at 6:31 PM, Mark Andrews  wrote:
>>
>>
>>
>> Named now uses NS lookups to perform QNAME minimisation.  If one puts
>> garbage in the NS
>> records then they should expect lookups to fail.  The NS records on both
>> sides of a zone
>> cut are supposed to be IDENTICAL.  This is not a new requirement.  It has
>> been this way
>> since the very beginning.
>>
>> The bank needs to fix what they publish.
>>
>> Mark
>>
>> On 28 Oct 2023, at 02:36, Michael Martinell via bind-users <
>> bind-users@lists.isc.org> wrote:
>>
>> Hello,
>> At this point I am hoping that somebody might have a workaround so that
>> we can exclude domains from this behavior if they are broken on the far
>> end. Does anybody have a workaround for this?
>> We are a small ISP and run BIND compiled from source. We currently run
>> 9.16.x
>> Every time we try to move forward with 9.18 customers start to complain
>> that they are unable to reach certain websites.  This includes banks,
>> universities, and other organizations.
>> I understand the goal is to get all DNS to RFC 6891, but from a practical
>> standpoint, this isn’t working for customers, so we are prevented from
>> upgrading either.
>> Related website:
>> https://gitlab.isc.org/isc-projects/bind9/-/issues/3152
>> Our source code compile options:
>> ./configure --with-gnu-ld --with-libxml2 --with-json-c
>> --with-openssl=/usr/local/openssl && make && make install && ldconfig
>>
>>
>>
>> Interstate Telecommunications Coop., Inc.
>> 312 4th Street West • Clear Lake, SD 57226
>> Phone: (605) 874-8313
>> michael.martin...@itccoop.com
>> www.itc-web.com
>>
>>
>>
>> --
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>> from this list
>>
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
-- 
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: 9.18 BIND not iterated over all authoritative nameservers

[Paul Stead]

As a previous ISP admin I too have come across similar situations and
frustrations.

I can only say that Google and Cloudflare seem to follow Postel's Law
moreso than BIND.

I agree this perpetuates bad practices but end users aren't interested in
technical reasoning, especially when "it works everywhere else, you must be
broken"

Paul


On Sat, Oct 28, 2023, 3:56 PM Rick Frey  wrote:

> As Mark mentions, the NS records gtm.bankeasy.com need to be corrected
> and failure is not due to lack of iterating through all auth nameservers
> (all of the auth nameservers have the bad NS record anyway).
>
> Not sure how many other domains you are running into similar problem, but
> you could disable qname-minimization in 9.18 to mimic previous behavior of
> 9.16 if that number is large.  I believe qname-minimization is a global
> directive so it would remove privacy benefits of QNAME minimization for all
> recursive queries from your nameserver.
>
> As DNS admin of another ISP, I sympathize dealing with failures caused by
> non-compliant authoritative nameservers.  These non-compliant auth
> nameservers can have little motivation to fix, especially when other large
> ISPs or public resolvers (looking at you Google and Cloudflare) don’t
> enforce DNS standards.   Many non-compliant nameservers/records would be
> cleaned up if public/centralized DNS providers such as Google/Cloudflare
> would enforce since it would inflict those failures on a much larger user
> base.
>
>  - Rick
>
>
>
> On Oct 27, 2023, at 6:31 PM, Mark Andrews  wrote:
>
>
>
> Named now uses NS lookups to perform QNAME minimisation.  If one puts
> garbage in the NS
> records then they should expect lookups to fail.  The NS records on both
> sides of a zone
> cut are supposed to be IDENTICAL.  This is not a new requirement.  It has
> been this way
> since the very beginning.
>
> The bank needs to fix what they publish.
>
> Mark
>
> On 28 Oct 2023, at 02:36, Michael Martinell via bind-users <
> bind-users@lists.isc.org> wrote:
>
> Hello,
> At this point I am hoping that somebody might have a workaround so that we
> can exclude domains from this behavior if they are broken on the far end.
> Does anybody have a workaround for this?
> We are a small ISP and run BIND compiled from source. We currently run
> 9.16.x
> Every time we try to move forward with 9.18 customers start to complain
> that they are unable to reach certain websites.  This includes banks,
> universities, and other organizations.
> I understand the goal is to get all DNS to RFC 6891, but from a practical
> standpoint, this isn’t working for customers, so we are prevented from
> upgrading either.
> Related website:
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3152
> Our source code compile options:
> ./configure --with-gnu-ld --with-libxml2 --with-json-c
> --with-openssl=/usr/local/openssl && make && make install && ldconfig
>
>
>
> Interstate Telecommunications Coop., Inc.
> 312 4th Street West • Clear Lake, SD 57226
> Phone: (605) 874-8313
> michael.martin...@itccoop.com
> www.itc-web.com
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind forgets my changes with nsupdate

[Paul van der Vlis via bind-users]

Op 06-10-2023 om 10:39 schreef Mark Andrews:

You need to figure out what is updating the zone. This isn’t named.


Thanks for your answer.
It makes me find the reason. See my other message.

With regards,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/
--
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 forgets my changes with nsupdate

[Paul van der Vlis via bind-users]

Op 06-10-2023 om 10:28 schreef Paul van der Vlis via bind-users:

Hello,

I try to give a dynamic IP to a name, using nsupdate. This works fine, 
but after some hours the IP is gone from the master (which I update).


Something like this:
Host home.customer.nl not found: 3(NXDOMAIN)

The IP is then still available from the slaves, what gets it from the 
master.


I do something like this to give the IP, using a script:

root@server:~# /usr/bin/nsupdate -k /etc/customer.key
 > server ns1.vandervlis.nl
 > zone customer.nl.
 > update delete home.customer.nl.
 > update add home.customer.nl. 3600 A 1.2.3.4
 > send
 > quit

I don't see anything about the removal in the logs. But I saw a "freeze" 
and a "thaw" in the logs for the domain.


Any idea why the IP removes after some time?


Hmm, I see I have cronjob what causes this problem:

-
# change serial
SERIAL=`named-checkzone $domain $domain | egrep -ho '[0-9]{10}'`
sed -i 's/'$SERIAL'/'$(($SERIAL+1))'/' $domain

# sign zone
rndc freeze $domain
dnssec-signzone -S -K /etc/bind/keys/ -g -a -o $domain $domain
rndc reload $domain
rndc thaw $domain
-

But how could I refresh the key without loosing the IP?

With regards,
Paul





--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/
--
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 forgets my changes with nsupdate

[Paul van der Vlis via bind-users]

Hello,

I try to give a dynamic IP to a name, using nsupdate. This works fine, 
but after some hours the IP is gone from the master (which I update).


Something like this:
Host home.customer.nl not found: 3(NXDOMAIN)

The IP is then still available from the slaves, what gets it from the 
master.


I do something like this to give the IP, using a script:

root@server:~# /usr/bin/nsupdate -k /etc/customer.key
> server ns1.vandervlis.nl
> zone customer.nl.
> update delete home.customer.nl.
> update add home.customer.nl. 3600 A 1.2.3.4
> send
> quit

I don't see anything about the removal in the logs. But I saw a "freeze" 
and a "thaw" in the logs for the domain.


Any idea why the IP removes after some time?

With regards,
Paul van der Vlis



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/
--
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: consolidating in-addr.arpa data

[Paul Kosinski via bind-users]

On Sat, 16 Sep 2023 10:22:26 +0100 (BST)
"G.W. Haywood via bind-users"  wrote:

> Hi there,
> ...
>I'd be surprised if the OP couldn't manage with 2^20 IPs in a segment -
> but then I guess he does work in the .gov domain.
   ^^^
  
The OP's contact email is "@alaska.gov".  Since the population of Alaska is 
only about 3/4 million (well below 2^20), I can't imagine that alaska.gov would 
possibly need more than one 10.0.0.0/8 IPv4 address per person in Alaska.  :-)
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Controlling which interface named uses

[Paul Kosinski via bind-users]

On Sat, 10 Jun 2023 19:24:03 +0200
Ondřej Surý  wrote:

> You are over-complicating things. If unconfigured, named binds the outgoing 
> UDP to 0.0.0.0 (::0), which means the chosen IP address is picked by the 
> kernel. You need to configure priorities on your interfaces in the kernel - 
> ip route is your friend.
> 
> And for goddess’ sake, don’t do anything wild like proposed round robin 
> across default routes. That would be a living hell to debug.
> 
> Ondřej
> --
> Ondřej Surý — ISC (He/Him)




If you have some external interfaces you *don't* want named to use, but might 
want other outgoing traffic to use, you would need some "policy based routing", 
which can get complicated. In Linux, this is controlled by "ip rule" (not "ip 
route").
-- 
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: Correlation between NOTIFY-Source and AXFR-Source

[Paul Stead]

Sorry I should have made it clearer that the notifier should only be
shuffled to the top of the list if it is a defined primary for said zone.

I.e An IP on the notify-from list, but not a configured primary wouldn't be
in the list of primaries for that zone so would not be shuffled to the top
of the list.

Anand has done a better job at describing this function in other software
than my attempts

Paul


On Sat, 11 Mar 2023, 17:16 Grant Taylor via bind-users, <
bind-users@lists.isc.org> wrote:

> Hi Paul,
>
> Thank you for explaining.
>
> On 3/10/23 12:21 AM, Paul Stead wrote:
> > Imagine that 1.1.1.1 has lost network connectivity recently. A notify
> > comes from 2.2.2.2 - if I understand correctly Bind will try 1.1.1.1
> > first, time out and then try 2.2.2.2 - even though we know given the
> > situation that 2.2.2.2 has the latest copy of the zone we want.
>
> I guess what I don't understand is why it's a problem for BIND to follow
> the configuration that's on the system where it's running.
>
> N.B. I am quite certain that I've sent notifications from a system that
> wasn't a DNS server before.  I don't remember if it was dig or something
> else.
>
> I only see a loose suggestion that BIND can do a zone transfer from the
> system that it received notifications from.
>
> I could see having a hierarchy with multiple public secondaries which
> transfer from the hidden private mname as well as multiple public
> tertiaries which transfer from the secondaries and configuring the
> hidden private mname to send notifications to all servers.
>
> Perhaps the larger spirit of this thread is if that association can be
> made hard or not.
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Correlation between NOTIFY-Source and AXFR-Source

[Paul Stead]

On Thu, 9 Mar 2023, 23:53 Grant Taylor via bind-users, <
bind-users@lists.isc.org> wrote:

> On 3/9/23 2:25 PM, Paul Stead wrote:
> > Chiming in to say +1 to Kalus' logic and sight of benefit here.
>
> Please forgive my ignorance in asking:
>
> Why doesn't the order of the configured primaries suffice?
>
> N.B. I'm assuming that this is the the order of the primaries for a zone
> in the named.conf file and not actually zone contents.
>
> What am I failing to understand?
>

For much the reasons Klaus cited, really.

Given the example:

masters {
  1.1.1.1
  2.2.2.2
};

Imagine that 1.1.1.1 has lost network connectivity recently. A notify comes
from 2.2.2.2 - if I understand correctly Bind will try 1.1.1.1 first, time
out and then try 2.2.2.2 - even though we know given the situation that
2.2.2.2 has the latest copy of the zone we want.

For what it's worth, NSD also seems to follow the logic of using the
notifier as the next master/primary to target - xfrd.c -
xfrd_handle_passed_packet

Paul
-- 
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: Correlation between NOTIFY-Source and AXFR-Source

[Paul Stead]

On Thu, 9 Mar 2023, 20:27 Klaus Darilion via bind-users, <
bind-users@lists.isc.org> wrote:

> > -Ursprüngliche Nachricht-
> > Von: bind-users  Im Auftrag von Mark
> > Andrews
> > Gesendet: Donnerstag, 9. März 2023 21:04
> >
> > Named just uses the notify to trigger an early refresh process. It then
> just asks
> > the primaries in configured order.There is no real point in trying the
> notifier
> > first.
>
> It depends. If one of the primaries is faster then the other in updating
> its version of the zone, named as secondary would have the update faster if
> it talks to fastest primary first. So there can be a benefit. Also if a
> primary is not reachable, for example maintenance and network issues, then
> named would not have to wait for timeouts before asking other primaries. So
> I see benefits.
>

Chiming in to say +1 to Kalus' logic and sight of benefit here.
-- 
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: automatic reverse and forwarding zones

[Paul Ebersman]

grant> I'd be interested in learning what other things /require/ or are
grant> at least predicated on having PTR records for IPs.

Been a few years since I last delved but was appalled at some of the
pointless uses of rev-ptrs. NYT used to require it to let you connect to
their website, as one such totally pointless use.

Reality is that the only way to find out is see if users scream or do
PTRs for all your addrs. For v6, on the fly generation is less broken
than trying to depend on DHCPv6 server dynamic DNS updates (doesn't help
for SLAAC). Someone has already mentioned that knot supports this.

On the plus side, most idiots checking for rev-ptr only care if they get
an answer. Unlike SMTP, where MTAs might check if forward and reverse
match, as long as they get an answer, they go away fat, dumb and happy.
-- 
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: ,Re: caching does not seem to be working for internal view

[Paul Kosinski via bind-users]

On Wed, 3 Aug 2022 15:10:39 -0400
Timothe Litt  wrote:

> Hmm.  Your resolv.conf says that it's written by NetworkManager.
> 
> What I suggested should have stopped it from updating resolv.conf.
> 
> See 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/manually-configuring-the-etc-resolv-conf-file_configuring-and-managing-networking
> 
> After restarting the service, did you edit (or replace) resolv.conf to 
> remove the AT address?
> 
> If not, stop here & edit the file.
> 
> If so, perhaps some other manager is editing the file without replacing 
> the comment.
> 
> Check to see if resolv.conf is a symlink - some managers (e.g. 
> systemd-resolved) will do that.  Not sure when/if it found its way to 
> centos (I don't run it), but if it's there, systemctl stop & disable 
> it.  It would be running on 127.0.0.53:53, but it usually points 
> resolv.conf to itself.
> 
> The other managers that I know of aren't in redhat distributions.
> 
> You may need to use auditing to identify what is writing the file.
> 
> Timothe Litt
> ACM Distinguished Engineer


"Helpful" software such as NetworkManager has a habit of getting in the way of 
figuring out what is wrong with systems, especially networked ones. Since none 
of the 8 computers on my home LAN are ever used in different locations, I don't 
use NetworkManager (etc.): I don't see why such add-ons are useful unless the 
computer is used on multiple networks. But distros install a lot of stuff in an 
attempt to "simplify" Linux for newbies. (Even Windows, which now may have more 
millions of experienced users than brand new users, acts as if no one has ever 
used a computer before.)

-- 
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: Stopping ddos

[Paul Kosinski via bind-users]

On Wed, 3 Aug 2022 13:47:41 +0200
Victor Johansson via bind-users  wrote:

> Hey,
> 
> I just want to add that there is a better way to do this in iptables 
> with hashlimit. The normal rate limit in iptables is too crude.
> 
> Below is an example from the rate-limit-chain, to which you simply send 
> all port 53 traffic from the INPUT chain (make sure to exclude 
> 127.0.0.1/127.0.0.53 though :) ).
> 
> 
> -A INPUT -p udp -m udp --dport 53 -j DNS-RATE-LIMIT
> -A INPUT -p tcp -m tcp --dport 53 -j DNS-RATE-LIMIT
> 
> -A DNS-RATE-LIMIT -s 127.0.0.1/32 -m comment --comment "Dont rate-limit 
> localhost" -j RETURN
> -A DNS-RATE-LIMIT -m hashlimit --hashlimit-upto 100/sec 
> --hashlimit-burst 300 --hashlimit-mode srcip --hashlimit-name DNS-drop 
> --hashlimit-htable-expire 2000 -j ALLOW
> -A DNS-RATE-LIMIT -m limit --limit 1/sec -j LOG --log-prefix "DNS-drop: "
> -A DNS-RATE-LIMIT -m comment --comment "ansible[dns rate limiting]" -j DROP
> 
> 
> //Victor
>


I was using iptables hashlimit for a while but stopped. It wasn't really 
solving my main problem, which was not so much "overloading" my BIND server as 
causing my log files to get filled with useless warnings about bad queries (or 
packets dropped).

It would be nice if BIND had way to record such error messages into a dumpable 
table with query, source IP and count.

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

DNSSEC adoption

[Paul Kosinski via bind-users]

There has been lots of discussion recently about DNSSEC issues, including 
whether it's desirable to sign internal zones. Independent of this most recent 
issue, a couple of weeks ago I did an informal survey, using DNSVIZ, of various 
TLDs. I found the following rather surprising results:

DNS-VIZ and "associates"

TLD Signed? Comments
--  --- 
dnsviz.net  yes with 1 warning (!)
iana.orgyes
icann.org   yes
isc.org yes
arin.netyes
ietf.orgyes with many warnings & errors

sandia.gov  yes with many warnings & 1 error
verisign.comyes
dns-oarc.netyes


Widely used and/or hi-tech

TLD Signed? Comments
--  --- 
google.com  no
gmail.com   no
youtube.com no
apple.com   no
microsoft.com   no
amazon.com  no
walmart.com no
outlook.com no
1e100.net   no
facebook.comno
twitter.com no
instagram.com   no
ibm.com no
mozilla.org no
wikipedia.org   no
redhat.com  no
w3c.org no
bankofamerica.com no

Does anybody have an explanation for why such big domains don't bother using 
DNSSEC?


P.S.  My opinion is that it probably worthwhile to sign internal zones, 
especially for organizations that are tempting targets and have many internal 
computers.

-- 
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: Problem resolving a domain

[Paul Stead]

Agreed, but without the upstream provider actually fixing the issue I
couldn't find a way to provide resolution of this domain to my customers -
are there better ways to resolve this from our side?

There seems to be a document about this issue -
https://kb.isc.org/docs/aa-01387

Paul

On Fri, 13 May 2022 at 14:07, Mark Andrews  wrote:

> Working around servers that drop queries causes problems for zones that do
> have protocol compliant servers.   The workarounds cause problems with
> getting DNSSEC responses wic leads to validation failures.
>
> --
> Mark Andrews
>
> On 13 May 2022, at 22:58, Paul Stead  wrote:
>
> 
> Further to this, I've discovered that disabling DNS cookies also seems to
> help with resolution -
>
> $ dig +nocookie +timeout=1 +retries=0 IN A
> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>
> Maybe the send-cookie option could be investigated? YMMV..
>
> On a side note other recursive DNS software seem to fall back gracefully
> and resolve these problems
>
> Paul
>
> On Fri, 13 May 2022 at 13:51, Paul Stead  wrote:
>
>> I have noticed this, too,
>>
>> The problem seems to be related to edns - disabling edns for the upstream
>> servers looks to resolve the issue, this can be seen with later versions of
>> dig -
>>
>> $ dig *+noedns* +timeout=1 +retries=0 IN A
>> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>>
>> I have config along the lines of -
>>
>> server 157.83.102.245 {
>>   edns no;
>> };
>>
>> for each of the problematic upstreams. I contacted Barclays a few months
>> ago about this, but never got a solid response.
>>
>> Paul
>>
>> On Fri, 13 May 2022 at 13:12, Ondřej Surý  wrote:
>>
>>> Hi Rainer,
>>>
>>> I believe this is unrelated to any upgrade. The nameservers for the
>>> domain are broken:
>>>
>>> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
>>> myapplication.international.barclays.com @ns2.barcap.com.
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
>>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
>>> ;; WARNING: recursion requested but not available
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 1220
>>> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
>>> ;; QUESTION SECTION:
>>> ;myapplication.international.barclays.com. IN A
>>>
>>> ;; ANSWER SECTION:
>>> myapplication.international.barclays.com. 900 IN CNAME
>>> myapplication.glbaa.barclays.com.
>>>
>>> ;; AUTHORITY SECTION:
>>> glbaa.barclays.com. 900 IN  NS  ns22.barclays.net.
>>> glbaa.barclays.com. 900 IN  NS  ns21.barclays.com.
>>> glbaa.barclays.com. 900 IN  NS  ns24.barclays.net.
>>> glbaa.barclays.com. 900 IN  NS  ns23.barclays.com.
>>>
>>> ;; ADDITIONAL SECTION:
>>> ns21.barclays.com.  900 IN  A   157.83.102.245
>>> ns23.barclays.com.  900 IN  A   157.83.126.245
>>> ns22.barclays.net.  600 IN  A   157.83.102.246
>>> ns24.barclays.net.  600 IN  A   157.83.126.246
>>>
>>> ;; Query time: 196 msec
>>> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
>>> ;; WHEN: Fri May 13 14:08:49 CEST 2022
>>> ;; MSG SIZE  rcvd: 283
>>>
>>>
>>> and the nameservers itself just timeout:
>>>
>>> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
>>> ns21.barclays.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
>>> +timeout +retries IN A myapplication.glbaa.barclays.com. @
>>> ns21.barclays.com.
>>> ;; global options: +cmd
>>> ;; connection timed out; no servers could be reached
>>>
>>>
>>> DNSVIZ gives the same result:
>>>
>>> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>>>
>>> • glbaa.barclays.com zone: The server(s) were not responsive to
>>> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
>>> 157.83.126.246)
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý (He/Him)
>>> ond...@isc.org
>>>
>

Re: Problem resolving a domain

[Paul Stead]

Further to this, I've discovered that disabling DNS cookies also seems to
help with resolution -

$ dig +nocookie +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
@ns21.barclays.com.

Maybe the send-cookie option could be investigated? YMMV..

On a side note other recursive DNS software seem to fall back gracefully
and resolve these problems

Paul

On Fri, 13 May 2022 at 13:51, Paul Stead  wrote:

> I have noticed this, too,
>
> The problem seems to be related to edns - disabling edns for the upstream
> servers looks to resolve the issue, this can be seen with later versions of
> dig -
>
> $ dig *+noedns* +timeout=1 +retries=0 IN A
> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>
> I have config along the lines of -
>
> server 157.83.102.245 {
>   edns no;
> };
>
> for each of the problematic upstreams. I contacted Barclays a few months
> ago about this, but never got a solid response.
>
> Paul
>
> On Fri, 13 May 2022 at 13:12, Ondřej Surý  wrote:
>
>> Hi Rainer,
>>
>> I believe this is unrelated to any upgrade. The nameservers for the
>> domain are broken:
>>
>> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>>
>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
>> myapplication.international.barclays.com @ns2.barcap.com.
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
>> ;; WARNING: recursion requested but not available
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1220
>> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
>> ;; QUESTION SECTION:
>> ;myapplication.international.barclays.com. IN A
>>
>> ;; ANSWER SECTION:
>> myapplication.international.barclays.com. 900 IN CNAME
>> myapplication.glbaa.barclays.com.
>>
>> ;; AUTHORITY SECTION:
>> glbaa.barclays.com. 900 IN  NS  ns22.barclays.net.
>> glbaa.barclays.com. 900 IN  NS  ns21.barclays.com.
>> glbaa.barclays.com. 900 IN  NS  ns24.barclays.net.
>> glbaa.barclays.com. 900 IN  NS  ns23.barclays.com.
>>
>> ;; ADDITIONAL SECTION:
>> ns21.barclays.com.  900 IN  A   157.83.102.245
>> ns23.barclays.com.  900 IN  A   157.83.126.245
>> ns22.barclays.net.  600 IN  A   157.83.102.246
>> ns24.barclays.net.  600 IN  A   157.83.126.246
>>
>> ;; Query time: 196 msec
>> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
>> ;; WHEN: Fri May 13 14:08:49 CEST 2022
>> ;; MSG SIZE  rcvd: 283
>>
>>
>> and the nameservers itself just timeout:
>>
>> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
>> ns21.barclays.com.
>>
>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
>> +timeout +retries IN A myapplication.glbaa.barclays.com. @
>> ns21.barclays.com.
>> ;; global options: +cmd
>> ;; connection timed out; no servers could be reached
>>
>>
>> DNSVIZ gives the same result:
>>
>> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>>
>> • glbaa.barclays.com zone: The server(s) were not responsive to
>> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
>> 157.83.126.246)
>>
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org
>>
>> My working hours and your working hours may be different. Please do not
>> feel obligated to reply outside your normal working hours.
>>
>> > On 13. 5. 2022, at 13:54, Rainer Duffner 
>> wrote:
>> >
>> > Hi,
>> >
>> > at work, I have a problem resolving the following domain:
>> >
>> > myapplication.international.barclays.com
>> >
>> >
>> > BIND 9.16.27, FreeBSD 12.3-P5.
>> > 2022Q2 ports.
>> >
>> >
>> > I copied the config to a VM at home - but it did not work there, either.
>> >
>> > I believe it must have happened on the update from BIND 9.16.26 to
>> 9.16.27.
>> >
>> >
>> > options {
>> >directory   "/usr/local/etc/namedb/working";
>> >pid-file"/var/run/named/pid";
>> >dump-file   "/var/dump/named_dump.db";
>> >statistics-file "/var/stats/named.stats";
>> > 

Re: Problem resolving a domain

[Paul Stead]

I have noticed this, too,

The problem seems to be related to edns - disabling edns for the upstream
servers looks to resolve the issue, this can be seen with later versions of
dig -

$ dig *+noedns* +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
@ns21.barclays.com.

I have config along the lines of -

server 157.83.102.245 {
  edns no;
};

for each of the problematic upstreams. I contacted Barclays a few months
ago about this, but never got a solid response.

Paul

On Fri, 13 May 2022 at 13:12, Ondřej Surý  wrote:

> Hi Rainer,
>
> I believe this is unrelated to any upgrade. The nameservers for the domain
> are broken:
>
> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>
> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
> myapplication.international.barclays.com @ns2.barcap.com.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1220
> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
> ;; QUESTION SECTION:
> ;myapplication.international.barclays.com. IN A
>
> ;; ANSWER SECTION:
> myapplication.international.barclays.com. 900 IN CNAME
> myapplication.glbaa.barclays.com.
>
> ;; AUTHORITY SECTION:
> glbaa.barclays.com. 900 IN  NS  ns22.barclays.net.
> glbaa.barclays.com. 900 IN  NS  ns21.barclays.com.
> glbaa.barclays.com. 900 IN  NS  ns24.barclays.net.
> glbaa.barclays.com. 900 IN  NS  ns23.barclays.com.
>
> ;; ADDITIONAL SECTION:
> ns21.barclays.com.  900 IN  A   157.83.102.245
> ns23.barclays.com.  900 IN  A   157.83.126.245
> ns22.barclays.net.  600 IN  A   157.83.102.246
> ns24.barclays.net.  600 IN  A   157.83.126.246
>
> ;; Query time: 196 msec
> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
> ;; WHEN: Fri May 13 14:08:49 CEST 2022
> ;; MSG SIZE  rcvd: 283
>
>
> and the nameservers itself just timeout:
>
> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
> ns21.barclays.com.
>
> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
> +timeout +retries IN A myapplication.glbaa.barclays.com. @
> ns21.barclays.com.
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
>
> DNSVIZ gives the same result:
>
> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>
> • glbaa.barclays.com zone: The server(s) were not responsive to
> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
> 157.83.126.246)
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> > On 13. 5. 2022, at 13:54, Rainer Duffner  wrote:
> >
> > Hi,
> >
> > at work, I have a problem resolving the following domain:
> >
> > myapplication.international.barclays.com
> >
> >
> > BIND 9.16.27, FreeBSD 12.3-P5.
> > 2022Q2 ports.
> >
> >
> > I copied the config to a VM at home - but it did not work there, either.
> >
> > I believe it must have happened on the update from BIND 9.16.26 to
> 9.16.27.
> >
> >
> > options {
> >directory   "/usr/local/etc/namedb/working";
> >pid-file"/var/run/named/pid";
> >dump-file   "/var/dump/named_dump.db";
> >statistics-file "/var/stats/named.stats";
> >allow-recursion {"rec";};
> >allow-query-cache { localhost; "rec" ; };
> >// CIS recommended:
> >// serverid none;
> >// dnssec-enable yes;
> >// dnssec-validation auto;
> >// dnssec-accept-expired no;
> >
> >listen-on   { 192.168.1.61; };
> >
> >disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
> >disable-empty-zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
> >disable-empty-zone
> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
> >
> > };
> >
> > acl rec {
> >127.0.0.0/8;
> >192.168.1.0/24;
> >::1;
> > };
> >
> > /*  Serving th

RE: Chroot Bind failed to start

[Paul Amaral via bind-users]

Reindi, thanks for the explanation, I do manually edit the zones because we 
don’t make many DNS changes these days and I usually do named-checkzone but I 
missed that this time, although I did reload that problematic zone with rndc 
reload and saw no errors.  I do have bind restarting once a week via chron. It 
restarted early this morning and of course it failed to come up with no errors 
in the log, making it difficult to troubleshoot ☹.

Paul

-Original Message-
From: bind-users  On Behalf Of Reindl Harald
Sent: Tuesday, March 15, 2022 10:01 AM
To: bind-users@lists.isc.org
Subject: Re: Chroot Bind failed to start



Am 15.03.22 um 14:37 schrieb Paul Amaral via bind-users:
> Neverminded, I was able to traceback my steps and realize a fat 
> fingered a DNS entry in one of the zones,  added two periods to an 
> authoritative zone’s DNS record, causing bind to fail to start. The 
> concerning issue was there was no error on the logs at all, making it 
> hard to figure out the issue.

that's the terrible packaging

> Which leads me to the next question, let’s say I’m authoritative for 
> regular zone ABC.com and I fat fingered its DNS record, 
> ns1..something.com. Why would this affect the bind instance from 
> starting up?

because that's what ExecStartPre is for
if it fails the unit fails

> Like I said there was nothing on the logs and I understand that might 
> be due to the Centos PKG itself. Just wondering why that mistake down 
> bind down and how I can get more meaningful logs on the logs even 
> those a prepackaged bind version.

the ExecStartPre happens long before named it even tried to start, so it can't 
log anything - in my opinion the ExecStartPre stuff should go in it's own 
script and just log but not fail the unit with a non-zero exit code

BTW: don't write directly in zone files and if you do so verify it at your own 
- good chances named would refuse to start at it's own with such errors

that's why you *don't hard restart named* just because you changed a zone - a 
reload most likely would have logged the error and just refused to reload the 
zone itself

you need tools for altering zones which would refuse such wrong input before 
they make it into the zone-file


-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Chroot Bind failed to start

[Paul Amaral via bind-users]

Neverminded, I was able to traceback my steps and realize a fat fingered a
DNS entry in one of the zones,  added two periods to an authoritative zone’
s DNS record, causing bind to fail to start. The concerning issue was there
was no error on the logs at all, making it hard to figure out the issue.



Which leads me to the next question, let’s say I’m authoritative for
regular zone ABC.com and I fat fingered its DNS record, ns1..something.com.
Why would this affect the bind instance from starting up? Like I said there
was nothing on the logs and I understand that might be due to the Centos PKG
itself. Just wondering why that mistake down bind down and how I can get
more meaningful logs on the logs even those a prepackaged bind version.



TIA

Paul





From: bind-users  On Behalf Of Paul Amaral
via bind-users
Sent: Tuesday, March 15, 2022 9:08 AM
To: 'bind-users@lists.isc.org' 
Subject: Chroot Bind failed to start



Hi, I realize this is related to Centos, but all the sudden chroot bind
failed to start up with any meaningful errors.

Anyone know what might be the issue here? I have no clues on that the issue
is.



Paul

Job for named-chroot.service failed because the control process exited with
error code. See "systemctl status named-chroot.service" and "journalctl -xe"
for details.



[r...@ns1.frv.ma:/var/named/meganet]#systemctl status named-chroot.service
-l

● named-chroot.service - Berkeley Internet Name Domain (DNS)

   Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled;
vendor preset: disabled)

   Active: failed (Result: exit-code) since Tue 2022-03-15 08:46:11 EDT;
6min ago

  Process: 3045 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" ==
"yes" ]; then /usr/sbin/named-checkconf -t /var/name d/chroot -z
"$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi
(code=exited, status=1/FAILURE)



Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service: control process
exited, code=exited status=1

Mar 15 08:46:11 ns1.frv.ma systemd[1]: Failed to start Berkeley Internet
Name Domain (DNS).

Mar 15 08:46:11 ns1.frv.ma systemd[1]: Unit named-chroot.service entered
failed state.

Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service failed.

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

Chroot Bind failed to start

[Paul Amaral via bind-users]

Hi, I realize this is related to Centos, but all the sudden chroot bind
failed to start up with any meaningful errors.

Anyone know what might be the issue here? I have no clues on that the issue
is. 

 

Paul 

Job for named-chroot.service failed because the control process exited with
error code. See "systemctl status named-chroot.service" and "journalctl -xe"
for details.

 

[r...@ns1.frv.ma:/var/named/meganet]#systemctl status named-chroot.service
-l

● named-chroot.service - Berkeley Internet Name Domain (DNS)

   Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled;
vendor preset: disabled)

   Active: failed (Result: exit-code) since Tue 2022-03-15 08:46:11 EDT;
6min ago

  Process: 3045 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" ==
"yes" ]; then /usr/sbin/named-checkconf -t /var/name d/chroot -z
"$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi
(code=exited, status=1/FAILURE)

 

Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service: control process
exited, code=exited status=1

Mar 15 08:46:11 ns1.frv.ma systemd[1]: Failed to start Berkeley Internet
Name Domain (DNS).

Mar 15 08:46:11 ns1.frv.ma systemd[1]: Unit named-chroot.service entered
failed state.

Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service failed.

-- 
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: Windows 9.16.25 fails to start (1067 Terminated unexpectedly)

[Paul Kosinski via bind-users]

On Thu, 17 Feb 2022 15:26:35 +0100
Ondřej Surý  wrote:

...
 
> This is part of the problem - debugging on Windows is extremely painful and 
> requires expertise with extremely high learning curve.
> 
> --
> Ondřej Surý — ISC (He/Him)

I wonder if difficult debugging is deliberate -- it would certainly make harder 
the reverse engineering of software from Microsoft and others who build on top 
of Windows.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Certbot rfc2136

[Paul van der Vlis]

Hi Mark, and others,

Op 25-10-2021 om 23:58 schreef Mark Andrews:




On 26 Oct 2021, at 08:02, Paul van der Vlis  wrote:

Hello,

I've made some progress..

Op 24-10-2021 om 21:39 schreef Paul van der Vlis:
(...)

I've tried to specify the "key-directory" in the bind configuration, but when I do that I 
get an error during "rndc reload", so I cannot specify a key-directory.  This is Bind 
9.16.15 from Debian 11.
What do I wrong?


What I did wrong here, is putting this key-directory option into the bind configuration 
(/etc/bind/named.conf). The correct place is in the zone, so I did put it in the 
"rndc modzone" command. This works ;-)


Well it can go in named.conf.  It needs to be in the options and/or view and/or 
zone sections.  This is documented.


OK..  Maybe it would work if I did put it in the options file.


But now I have a next problem:
--
Oct 25 22:27:53 ns1 kernel: [540901.362643] audit: type=1400 audit(1635193673.521:12): apparmor="DENIED" operation="mknod" 
profile="named" name="/etc/bind/zones/hallo24.nl.signed.jnl" pid=343 comm="isc-worker" requested_mask="c" 
denied_mask="c" fsuid=107 ouid=107
Oct 25 22:27:53 ns1 named[343]: /etc/bind/zones/hallo24.nl.signed.jnl: create: 
permission denied
--

Hmm, maybe it's not a good idea that bind would change those static 
configfiles. What I would like, is that bind would change only temporary the 
database in /var/cache/bind/ . Would that be possible?  Or do you have a better 
idea?


It’s not named’s job to update SELinux or AppArmour. I suspect we would get 
complaints if we attempted to do that.  Changing security policy is the job of 
the operator.


I know how to configure apparmor, my question is not about that.

My question is about what is a good way to implement rfc2136 in Bind.

I guess it's not a good idea that Bind really changes the zone-files in 
/etc/bind using rfc2136 because /etc is for static configuration data. 
But maybe I am wrong.


Is it the way to go to update Apparmor to make Bind write in /etc/bind , 
or is there a better way?


With regards,
Paul van der Vlis.

--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
___
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: Certbot rfc2136

[Paul van der Vlis]

Hello,

I've made some progress..

Op 24-10-2021 om 21:39 schreef Paul van der Vlis:
(...)
I've tried to specify the "key-directory" in the bind configuration, but 
when I do that I get an error during "rndc reload", so I cannot specify 
a key-directory.  This is Bind 9.16.15 from Debian 11.


What do I wrong?


What I did wrong here, is putting this key-directory option into the 
bind configuration (/etc/bind/named.conf). The correct place is in the 
zone, so I did put it in the "rndc modzone" command. This works ;-)


But now I have a next problem:
--
Oct 25 22:27:53 ns1 kernel: [540901.362643] audit: type=1400 
audit(1635193673.521:12): apparmor="DENIED" operation="mknod" 
profile="named" name="/etc/bind/zones/hallo24.nl.signed.jnl" pid=343 
comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=107 ouid=107
Oct 25 22:27:53 ns1 named[343]: /etc/bind/zones/hallo24.nl.signed.jnl: 
create: permission denied

--

Hmm, maybe it's not a good idea that bind would change those static 
configfiles. What I would like, is that bind would change only temporary 
the database in /var/cache/bind/ . Would that be possible?  Or do you 
have a better idea?


This is the rndc modzone command what I give at the moment:
--
rndc modzone hallo24.nl "{ type master; file 
\"/etc/bind/zones/hallo24.nl.signed\"; key-directory \"/etc/bind/keys\"; 
allow-transfer { 91.198.178.25; 2a01:1b0:7999:424::25; 45.95.238.187; 
2a10:3781:13b6::2; }; update-policy {grant test3.hallo24.nl. name 
_acme-challenge.test3.hallo24.nl. txt;}; };"

--

With regards,
Paul van der Vlis

--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
___
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

Certbot rfc2136

[Paul van der Vlis]

Hello,

I am trying to get Certbot working using rfc2136. But during the 
validation I get these errors:

---
Oct 24 02:14:21 ns1 named[343]: client @0x7f70e43b7d08 
45.95.238.187#57242/key test3.hallo24.nl: updating zone 'hallo24.nl/IN'
: adding an RR at '_acme-challenge.test3.hallo24.nl' TXT 
"qYxXiH34V8T0lFtsUOd_BPMZCBiA-FgAiJ-0nUGHsYE"
Oct 24 02:14:21 ns1 named[343]: dns_dnssec_findzonekeys2: error reading 
Khallo24.nl.+013+02962.private: file not found
Oct 24 02:14:21 ns1 named[343]: dns_dnssec_findzonekeys2: error reading 
Khallo24.nl.+013+01290.private: file not found

---

These files are in /etc/bind/keys/, and normally that's no problem.

I've tried to specify the "key-directory" in the bind configuration, but 
when I do that I get an error during "rndc reload", so I cannot specify 
a key-directory.  This is Bind 9.16.15 from Debian 11.


What do I wrong?


Does somebody know a good howto to get this working? I use now this:
https://certbot-dns-rfc2136.readthedocs.io/en/stable/
but in my opinion it's not complete enough.

With regards,
Paul







--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
___
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: Contents of bind-users digest...

[Paul Kosinski via bind-users]

On Tue, 6 Jul 2021 12:44:15 +
"MURTARI, JOHN"  wrote:

> Folks, let me add my desire for a quick download dig supporting DoH.  It 
> could really help with some testing, some ready stuff for Ubuntu 18/20,  
> Redhat/CentOS, could make a lot of people happy.   Maybe the libs included 
> and we set the LD_LIBRARY_PATH, or a 'static' link?
> 
> 
> It only takes a 'few minutes' more -- once you spend a few hours getting the 
> whole environment setup.  some don't build it all the time.
> 
> 
> I'll give ISC Five Stars on Google! 
> 
> 
> > On 6 Jul 2021, at 05:56, Eric Germann via bind-users 
> >  wrote:
> >
> > Has ISC given any thought to releasing dig as a separate source package?
> >
> > It?s good for testing DoH, but you need to build the entire bind package to 
> > get it.  It would be useful for support analysts without the overhead of 
> > compiling all of bind to get it  
> 
> Really, it a couple of extra megabytes of disk space and a couple of extra 
> minutes of compile
> time.  Dig is not a stand alone component.  It depends on libisc, libdns, 
> libisccfg, libirs, and
> libbind9.  Thats most of the libraries we build.  It makes no sense to have a 
> seperate source
> package for dig.


It isn't mainly the disk space and extra build time, it's the complexity. 
Somebody who only wants 'dig' would have to figure out how to isolate it from 
the result of the build. This would be especially troublesome after doing a 
"make install" (which I suspect is necessary to get the 'dig' executable 
properly set up) as there would be a whole lot of undesired stuff installed. 
Perhaps adding a "install-dig-only" option to the make file would be possible 
and not a lot of work?
___
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: Limit actions on control channel?

[Paul Kosinski via bind-users]

It ought to be possible to write a front-end to listen on the standard control 
channel and only forward (properly-keyed) 'status' requests to the "real" port 
that BIND listens to. 

>From looking at the RNDC exchange via Wireshark however, you'd have to adapt 
>some of BIND's code that does the encryption / key-signing of RNDC requests. 
>Still, for us users, that might be safer -- and more update resistant -- than 
>modifying BIND itself.


On Thu, 17 Jun 2021 11:48:36 -0800
John Thurston  wrote:

> I see I can define (using the 'controls' statement) a 'read-only' inet 
> channel. I suspect I could define a couple of channels on the same 
> address if I put them on different ports. Is there a way to define a 
> single 'read-write' channel, and then limit certain keys to read-only 
> access on it?
> 
> Here's the scenario:
> 
> I'd like to have a single control channel listening (on port 953, for 
> example). I'd like to say the key named "foo" can do lots of things, but 
> the key named "bar" can only submit a "status" message. This would let 
> our monitoring application ask for "status" without also letting it ask 
> for "reload" or "flushname".
> 
___
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: Need Help with BIND9

[Paul Kosinski via bind-users]

The site mxtoolbox.com has a suite of tools to check your DNS, email and Web 
servers from the outside. They're easy to use and might turn up something.


On Fri, 11 Jun 2021 09:10:32 -0700
techli...@phpcoderusa.com wrote:

> Hi,
> 
> The two domains I am working with on my SOHO home server are 1) 
> keiththewebguy.com  and 2) phpcodetest.com.
> 
> I setup keiththewebguy.com first and configured BIND9 for it on the same 
> server.
> 
> To try to troubleshoot I configured phpcodetest.com on the same box, 
> however it uses Zoneedit for DNS.  phpcodetest.com works as expected.
> 
> keiththewebguy.com does not work which uses my local BIND9.
> 
> I've tried everything I can think of.  I've tested the config files, run 
> dig, and verified port 53 is open.
> 
> I took the zone file for keiththewebguy.com from my VPS that runs Plesk 
> and previously hosted keiththewebguy.com.  I forgot to change the IP 
> addresses in the zone to my SOHO box and the website on my VPS was 
> accessible.  When I changed the IP addresses in the zone file to my SOHO 
> box the website quit working.
> 
> I assumed this meant I had an Apache issue and that is when I added 
> phpcodetest.com to test Apache.  I've checked apache several times...  
> And I just checked it again.
> 
> The server I am using is an old i3 laptop that I upgraded with a SSD.  
> It has 4GB RAM.
> 
> I am using Ubuntu 20.04lts and BIND9.
> 
> My connection is a commercial/business Internet connection provided by 
> my cable company for home office usage. This connection does not block 
> ports.
> 
> I followed the Ubuntu 20.04 server manual to configure BIND9 and I have 
> searched the Internet for more information.
> 
> If you need any additional information let me know.
> 
> Thank you for your help!!
___
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: No more support for windows

[Paul Kosinski via bind-users]

On Fri, 4 Jun 2021 13:58:40 -0700
Gregory Sloop  wrote:

> This feels a lot like responding to trolls, but I'll instead assume that 
> you're asking (or making a point) in good faith.
> 
> So, we'll stipulate that - you're actually interested in truth and knowledge.
> 
> So, it's easily compiled on Mac, Unix, FreeBSD, Linux, SunOS, RaspPi, etc.
> And it compiles on a huge range of hardware, CPU's etc.
> 
> I'd consider that highly portable.


I'd consider it moderately portable.

Among Open Source software, I'd consider the following highly portable: 
Firefox, Chromium, LibreOffice, Thunderbird, Claws-Mail, Scribus, Inkscape, 
Gimp, Krita, VLC, QT(!) and who knows how many others that run on Unix-like 
systems *and* on Windows.

And among closed source software, Chrome is obviously highly portable (by 
Google), and Acrobat Reader and Flash (RIP) are highly portable (by Adobe).

P.S. I am not a fan of Windows, but it is widespread, and many people even use 
it for Internet servers.
___
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: Syslog with BIND on CentOS

[Paul Kosinski via bind-users]

If you can have BIND log directly to a file, couldn't you use a FIFO 
(prwxrwxrwx) or Unix domain socket (srwxrwxrwx) and avoid the disk I/O by 
sending the log data directly to the forwarder? (E.g., Pulse Audio listens on a 
socket for audio data from an application, and sends it in real-time to the D/A 
hardware driver etc.)


On Fri, 21 May 2021 00:17:11 +0200
Anand Buddhdev  wrote:

> On 20/05/2021 23:34, John Thurston wrote:
> 
> Hi John,
> 
> > My subsequent read of the docs indicates that BIND on CentOS 7, while
> > being told it is sending to 'syslogd', is sending to 'journald' which is
> > handling all the messages and forwarding them on to 'syslogd'. I don't
> > want journald handling my thousands of messages per second from BIND. I
> > don't want that information in my journal logs. I just want it out in
> > the central syslog server.  
> 
> On CentOS, journald listens on the syslog socket, and intercepts ALL log
> messages, and logs them into files that are either in a memory-based
> tmpfs (the default), or to disk (if you configure journald that way).
> After intercepting the log message, and saving it to the journal,
> journald then forwards the message to rsyslog, which listens on a
> different socket.
> 
> > Is there some direct way to get the logging channel of BIND pointed
> > directly into the local syslogd? (which would then apply its forwarding
> > rules to get traffic to the central syslog server)  
> 
> As far as I know, BIND just calls the syslog functions, and so the log
> messages will go to whatever is listening on the default syslog socket
> (journald on CentOS). I don't think there's any way to point BIND to
> rsyslog's socket.
> 
> > I thought about trying to rip jourald out entirely, and quickly decided
> > that was a path to madness.  
> 
> That is indeed the path to madness. On systemd-based servers, you can't
> really do without journald.
> 
> > The only thing I can come up with is to activate dnstap, and have some
> > other process absorbing the data and spewing it directly to the central
> > syslogd.  
> 
> You could also log directly to files (bypassing syslog), and then have
> some process follow the files and send the logs to a remote server.
> 
> Regards,
> Anand

___
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: where are the testing docs ?

[Paul Kosinski via bind-users]

Actually, it's in keeping with the *original* definition of hacking!


On Sun, 9 May 2021 23:55:13 -0600
@lbutlr  wrote:

> On 06 May 2021, at 09:57, Dennis Clarke via bind-users 
>  wrote:
> > I do NOT trust a build result where I had to go hacking into all the
> > Makefiles just to get it to build. You install without doing testing?  
> 
> That's a very strange definition of "hacking". Setting makefile [preferences 
> and options is not in and way "hacking".
> 
___
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: Using RNDC to control remote access to my BIND server

[Paul Kosinski via bind-users]

A couple of years ago, I tried using nsupdate to modify a dynamic (DHCP) IP 
address for my very simple domain. It worked, except that it totally messed up 
the organization of the zone file. Since the file only has 44 active lines 
(which are organized logically), I maintain it by hand. After nsupdate made the 
one line change, the zone file became unmaintainable.

Was this a bug in nsupdate, or does nobody try to understand their zone files.

P.S. Now I use $INCLUDE and just overwrite the included file with the new A 
record (using a simple bash script via an encrypted connection).



On Fri, 23 Apr 2021 12:21:22 +0200
Anand Buddhdev  wrote:

> Hi Greg,
> 
> You don't need to SSH into a remote server to do dynamic DNS updates!
> The "nsupdate" tool can send the dynamic DNS updates directly to your
> remote server over the DNS protocol.
> 
> You appear to be confused about what the various tools do, so here's a
> summary:
> 
> 1. ssh is used to log into a remote server, get a shell, and run
> operating system commands.
> 
> 2. rndc is for controlling a running BIND server. It can be used to
> check the status of BIND, reload it, etc.
> 
> 3. nsupdate is for modifying a zone directly (whether on the local
> machine, or some remote machine) using the dynamic DNS protocol.
> 
> Having read your message, it seems that you need to use "nsupdate". You
> don't need "ssh" or "rndc" for this.
> 
> Regards,
> Anand
> 
> On 23/04/2021 11:50, Greg Donohoe wrote:
> 
> > Thank you for the suggestions. I am looking into those now.
> > Yes we can run nsupdate again on the remote server but I would still need
> > to connect to the remote server to do this.
> > We were thinking of using SSH to the remote server but we want to explore
> > any other option rather than SSH for the secure connection.
> > I was thinking that it may be possible to use RNDC or some other tool to
> > update the remote BIND server zone files (either by modifying the zone file
> > that is already there or replacing the zone file with the new one I created
> > locally).
> > RNDC looks like it is a non starter for what I want but nsdiff may be a
> > good option.  
___
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

[Paul Kosinski via bind-users]

Interesting, although we host different domains, in and from different 
geographic areas, we got the same queries as yours on the same day, with some 
at about the same time (we're EDT).

13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.365 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.366 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.568 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.820 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied


13-Apr-2021 03:04:25.379 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:25.553 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied

This is not a complete list, but they all were on Apr 13 (and near your times).

==

On Tue, 13 Apr 2021 15:23:20 +0100 (WET-DST)
Peter Coghlan  wrote:

> Hi Paul,
> 
> Many thanks for your reply.  Yours is exactly the sort of reply I was hoping
> for because I feel like I have been banging my head on a brick wall for months
> now looking for someone else who cares whether their nameserver is an engine
> for this sort of abuse.  I was beginning to wonder if I was the only person
> in the world seeing this kind of abuse and regarding it as a problem.
> 
> I will leave another while to see if more clueful replies like yours arrive
> and then I will reply back to the list again myself to try to move the thread
> in the direction of requesting a solution which can easily be implemented by
> anyone and does not involve packet filters, firewalls, IPtables and so on.
> 
> In the meantime, I thought it would be interesting to see if I also got
> the same abusive queries you logged below.  Unfortunately (or fortunately)
> I am packet filtering incoming queries with source port 80 so they did not
> make it as far as the logs in my case.  Here are a few that did make it to
> my logs.  Maybe they are in yours too?
> 
> Regards,
> Peter Coghlan.
> 
> 13-Apr-2021 06:20:10.867 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.396 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.743 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.804 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:32.746 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:32.935 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:33.993 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:34.047 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
___
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

[Paul Kosinski via bind-users]

Interesting observation. I just did lookups on 4 recent (< 24 hrs ago) 
'sl/ANY/IN' queries logged by our BIND and got:

2 Comcast cable IPs (hsd1.tx.comcast.net and hsd1.ma.comcast.net)
1 OVH Hosting IP (Montreal)
1 Afranet IP (Tehran!)

The whois info for the OVH IP contains the line:

  Comment:   Failover IPs


On Tue, 13 Apr 2021 14:04:14 -0700
Carl Byington via bind-users  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Tue, 2021-04-13 at 22:32 +0200, Julien Salort wrote:
> > 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.  
> 
> In the particular case of the .sl denied queries, I don't think these
> are forged queries from the attack victim. Something else is going on
> here. We see queries from systems like these, almost exclusively
> consumer endpoints:
> 
> 142-197-133-231.res.spectrum.com.
> mta-162-154-195-235.kya.rr.com.
> mobile-166-173-63-176.mycingular.net.
> prg03s05-in-f193.1e100.net.
> prg03s05-in-f1.1e100.net.
> pool-173-79-59-79.washdc.fios.verizon.net.
> 174-30-51-96.wrbg.centurylink.net.
> c-174-53-75-253.hsd1.va.comcast.net.
> 174-081-062-250.res.spectrum.com.
> cpe-174-106-58-62.ec.res.rr.com.
> 192.sub-174-214-12.myvzw.com.
> stop-looking-at-drifteds-ip.gov.
> 252.243.53.179.d.dyn.claro.net.do.
> ip184-186-26-40.no.no.cox.net.
> dsl-187-193-200-41-dyn.prod-infinitum.com.mx.
> dsl-189-178-58-206-dyn.prod-infinitum.com.mx.
> customer-189-216-112-75.cablevision.net.mx.
> 189.223.57.66.dsl.dyn.telnor.net.
> 212-149-157-12.rev.dnaip.fi.
> 
> It seems unlikely that someone is trying to attack those specific
> endpoints. Unless the attack is *very* widely distributed and they are
> actually attacking the ISP infrastructure. But in that case, this seems
> to be a simultaneous attack on almost every major ISP, which I find
> unlikely.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHYHGhUcY2FybEBmaXZl
> LXRlbi1zZy5jb20ACgkQL6j7milTFsG2xwCeNRKi5df2TdmaWyJQJhGCraf1UIoA
> n0zp1wmsrlc9yeDc/wXJCy8xBToC
> =Ir5g
> -END PGP SIGNATURE-
___
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

[Paul Kosinski via bind-users]

We also get *lots* of suspicious queries of the same kind, from various 
privileged and unprivileged ports, which I'm pretty sure are DDoS attempts. For 
example:

  12-Apr-2021 23:44:17.767 security: info: client 107.213.131.17#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:44:19.477 security: info: client 107.213.131.17#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:45:00.908 security: info: client 98.229.97.172#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:45:01.263 security: info: client 98.229.97.172#80 (sl): query 
(cache) 'sl/ANY/IN' denied

Besides not wanting to be an unwilling DDoS amplifier, these bother me because 
they're filling up my BIND/named log files.

I've tried using IPtables hashlimit to throttle the requests, but have had 
little success. I've even tried blocking the responses with IPtables packet 
content matching plus hashlimit, but that doesn't help my log files!



On Mon, 12 Apr 2021 20:41:13 +0100 (WET-DST)
Peter Coghlan  wrote:

> Hello,
> 
> I have a nameserver which is authoritative for three or four domain names.
> It receives around 1000 queries per day that could be regarded as plausably
> legitimate.  It receives around ten times that number of absive queries per
> day from presumably spoofed ip addresses, the vast majority of them IN ANY
> queries for the "sl" domain or for the root nameservers all of which my
> nameserver responds to with return code 5 ie refused.
> 
> In many cases, the source port is a low number such as 53, 80, 96 or 443
> for example which might make some sense if these were TCP queries but they
> are all UDP queries and apart from attempting to target port 53, attempting
> to target the other low UDP port numbers make no sense to me.
> 
> I have searched high up and low down for any discussion about this kind
> of abuse and found very little regarding abusive queries for the root
> nameservers, none at all regarding the sl domain (although it is a difficult
> term to search for) and nothing at all regarding the oddball source ports
> either.
> 
> Even though the "refused" responses from my nameserver are "small", the
> general persistence of the abusers over a long period of time suggests to
> me that they are finding these queries effective for some kind of abuse,
> perhaps by way of having a very large number of nameservers return them
> (unless they are too stupid to care whether the queries are answered or
> refused which I suppose is also possible).
> 
> As far as I can see providing no response at all in any instance when a
> code 5 refused response would normally be returned would be the appropriate
> thing for my nameserver to do here and doing this would cause no difficulties
> at all with any legitimate queries or anyone who is not an abuser.  Am I
> correct here?
> 
> I have searched for a way to prevent my nameserver from responding
> to these queries at all in order to reduce the impact on the targets
> of this abuse.  All results of my research point to the use of
> rate limiting as the only approach available for dealing with this
> sort of issue.
> 
> The abusive queries are clearly designed to circumvent the widely
> suggested "errors-per-second 5" as they arrive in groups of five
> per second and applying this limitation has little or no effect
> on them.
> 
> I have tried "errors-per-second 1" and this seems to reduce the abuse
> by about four fifths but one fifth of it still manages to get through
> and I don't find this acceptable.
> 
> Instead, when I notice particularly heavy abuse of my nameserver,
> I apply packet filtering to prevent the abusive queries from reaching
> my nameserver and therefore to prevent it responding to them.  I
> also routinely packet filter all UDP dns queries with source port
> numbers less than 1024 which I hope is the appropriate cutoff point.
> 
> Is there anything else I can do to reduce the impact of this abuse
> of my nameserver on others?
> 
> My feeling is that mine can't be the only nameserver experiencing this
> kind of abuse and that many nameserver admins probably would not even
> notice it unless they had query logging or query-error logging turned
> on and checked the logs.
> 
> Regards,
> Peter Coghlan.
___
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.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Kosinski via bind-users]

Well said! 


On Mon, 29 Mar 2021 16:11:54 +0100
Tony Finch  wrote:

> alcol alcol  wrote:
> 
> > seriously? is like linux/unix FAQ   
> 
> Please, if you can't be helpful, don't reply at all. We all have to learn
> somehow, and the best way to show your knowledge is to share it generously.
> 
> Tony.
___
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.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Cizmas]

Bruce, indeed the named is in 
/Applications/Server.app/Contents/ServerRoot/usr/sbin/named.  

> On Mar 26, 2021, at 12:20 PM, Bruce Johnson  
> wrote:
> 
> 
> 
>> On Mar 26, 2021, at 9:17 AM, Paul Cizmas  wrote:
>> 
>> Ondrej:
>> 
>> Thank you - I installed bind with brew.  It says it installed 9.16.13.  
>> However, it still seems that I am running 9.9.7-P3:
> 
> Make sure that the launchd plist for bind is pointing to the correct location 
> of named. (probably /usr/local/opt/bind/sbin judging from the screen shot)

Indeed, named is in /usr/local/opt/bind/sbin.  How can I “make sure that the 
launchd plist” is pointing to /usr/local/opt/bind/sbin?
> 
> 
> If the previous version was installed as part of Mac OS Server, or MacPorts, 
> for example that binary will live somewhere other than /usr/local.

Indeed again, the previous BIND, which is 9.9.7-P3, was installed as part of 
Mac OS Server.

Thank you, Paul 
> 
> -- 
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
> 
> Institutions do not have opinions, merely customs
> 

___
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.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Cizmas]

Tony, thank you!  I ran 'dig @localhost version.bind ch txt’ and got

~$ dig @localhost version.bind ch txt
md5.c:96: fatal error: RUNTIME_CHECK(pk11_get_session(ctx, OP_DIGEST, 1, 0, 0, 
((void *)0), 0) == 0) failed
Abort trap: 6

I do not know what this means.

I then ran 'which named’ and it is

/Applications/Server.app/Contents/ServerRoot/usr/sbin/named

When I ran rndc status I got

~$ rndc status
rndc: error: open: /Library/Server/named/rndc.key: permission denied
rndc: could not load rndc configuration

Thank you,
Paul

> On Mar 26, 2021, at 1:44 PM, Tony Finch  wrote:
> 
> Paul Cizmas  wrote:
> 
>> ~$ named -v
>> BIND 9.9.7-P3 (Extended Support Version)
> 
> What's probably happening here is that the BIND on your $PATH isn't
> necessarily the BIND that homebrew installed and (hopefully) is running.
> 
> You can run `dig @localhost version.bind ch txt` to see what the running
> server reports as its version.
> 
> You can run `which named` to find out where it is finding 9.9.7.
> 
> If you run `rndc status` it should fail, because of the mismatched
> installations (I expect your 9.9.7 will not look for the rndc key in the
> same place as 9.16.3) but `/usr/local/opt/bind/sbin/rndc status` ought to
> work and tell you about the running 9.16.3.
> 
> Tony.
> -- 
> f.anthony.n.finch
> https://urldefense.com/v3/__https://dotat.at/__;!!KwNVnqRv!X3SMvugQcNKGxCiqE5_jRKoYHw1W0s4vgKKIp5wzN-eZZHZJyrih8gMHTHqvak0$
>  
> Great Orme Head to the Mull of Galloway: Southwest veering west 6 to
> gale 8, backing southwest 5 to 7 later. Moderate, occasionally rough.
> Squally showers, rain later. Good, occasionally moderate.
> 

___
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.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Cizmas]

Ondrej:

Thank you - I installed bind with brew.  It says it installed 9.16.13.  
However, it still seems that I am running 9.9.7-P3:

~$ sudo brew services start bind
Password:
warning: unable to access '/Users/cizmas/.config/git/attributes': Permission 
denied
warning: unable to access '/Users/cizmas/.config/git/attributes': Permission 
denied
warning: unable to access '/Users/cizmas/.config/git/attributes': Permission 
denied
warning: unable to access '/Users/cizmas/.config/git/attributes': Permission 
denied
==> Tapping homebrew/services
Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-services'...
remote: Enumerating objects: 20, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 1141 (delta 8), reused 0 (delta 0), pack-reused 1121
Receiving objects: 100% (1141/1141), 331.53 KiB | 3.38 MiB/s, done.
Resolving deltas: 100% (484/484), done.
warning: unable to access '/Users/cizmas/.config/git/attributes': Permission 
denied
Tapped 1 command (39 files, 417.3KB).
Warning: Taking root:admin ownership of some bind paths:
  /usr/local/Cellar/bind/9.16.13/sbin
  /usr/local/Cellar/bind/9.16.13/sbin/named
  /usr/local/opt/bind
  /usr/local/opt/bind/bin
  /usr/local/opt/bind/sbin
This will require manual removal of these paths using `sudo rm` on
brew upgrade/reinstall/uninstall.
==> Successfully started `bind` (label: homebrew.mxcl.bind)
~$ named -v
BIND 9.9.7-P3 (Extended Support Version)

So, why is it still 9.9.7-P3?

Thank you,
Paul


> On Mar 26, 2021, at 9:25 AM, Ondřej Surý  wrote:
> 
> $ brew info bind
> bind: stable 9.16.13 (bottled), HEAD
> Implementation of the DNS protocols
> https://www.isc.org/bind/
> Not installed
> From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/bind.rb
> License: MPL-2.0
> ==> Dependencies
> Build: pkg-config ✔
> Required: json-c ✔, libidn2 ✔, libuv ✔, openssl@1.1 ✔, python@3.9 ✔
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
>> On 26. 3. 2021, at 15:02, Paul Cizmas  wrote:
>> 
>> Ondrej:
>> 
>> I did not think of doing it.  Let me try.  Thank you for your suggestion!
>> 
>> Paul
>> 
>>> On Mar 26, 2021, at 2:04 AM, Ondřej Surý  wrote:
>>> 
>>> Paul,
>>> 
>>> why don’t you just install BIND 9 from Homebrew?
>>> 
>>> Ondřej
>>> --
>>> Ondřej Surý — ISC (He/Him)
>>> 
>>> My working hours and your working hours may be different. Please do not 
>>> feel obligated to reply outside your normal working hours.
>>> 
>>>> On 26. 3. 2021, at 1:50, Paul Cizmas  wrote:
>>>> 
>>>> Hello:
>>>> 
>>>> I am new to BIND and I am trying to install version 9.16.13 on a Mac OS X 
>>>> 10.13.6.
>>>> 
>>>> I downloaded version 9.16.13 and, following the suggestions from 
>>>> https://krypted.com/mac-os-x/dns-install-bind-macos/, I am trying to 
>>>> configure using
>>>> 
>>>> ./configure --enable-symtable=none --infodir="/usr/share/info" 
>>>> --sysconfdir="/etc" --localstatedir="/var" --enable-atomic="no" 
>>>> --with-gssapi=yes --with-libxml2=no
>>>> 
>>>> This fails because of libuv
>>>> 
>>>> checking for pthread_set_name_np... no
>>>> checking for pthread_np.h... no
>>>> checking for libuv... checking for libuv >= 1.0.0... no
>>>> configure: error: libuv not found
>>>> 
>>>> I have libuv installed, however.  It is version 1.41.0.
>>>> 
>>>> I would appreciate any suggestions on how to fix this.
>>>> 
>>>> Thank you,
>>>> Paul
>>>> 
>>>> 
>>>> ___
>>>> 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
>> 
> 

___
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.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Cizmas]

Ondrej:

I did not think of doing it.  Let me try.  Thank you for your suggestion!

Paul

> On Mar 26, 2021, at 2:04 AM, Ondřej Surý  wrote:
> 
> Paul,
> 
> why don’t you just install BIND 9 from Homebrew?
> 
> Ondřej
> --
> Ondřej Surý — ISC (He/Him)
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
>> On 26. 3. 2021, at 1:50, Paul Cizmas  wrote:
>> 
>> Hello:
>> 
>> I am new to BIND and I am trying to install version 9.16.13 on a Mac OS X 
>> 10.13.6.
>> 
>> I downloaded version 9.16.13 and, following the suggestions from 
>> https://krypted.com/mac-os-x/dns-install-bind-macos/ 
>> <https://urldefense.com/v3/__https://krypted.com/mac-os-x/dns-install-bind-macos/__;!!KwNVnqRv!VKtxcs8uSs8lXFhO1gXTlYF3fXf6_KcijRBrODXxa-J071VqBTPozukV3ZHFV7Q$>,
>>  I am trying to configure using
>> 
>> ./configure --enable-symtable=none --infodir="/usr/share/info" 
>> --sysconfdir="/etc" --localstatedir="/var" --enable-atomic="no" 
>> --with-gssapi=yes --with-libxml2=no
>> 
>> This fails because of libuv
>> 
>> checking for pthread_set_name_np... no
>> checking for pthread_np.h... no
>> checking for libuv... checking for libuv >= 1.0.0... no
>> configure: error: libuv not found
>> 
>> I have libuv installed, however.  It is version 1.41.0.
>> 
>> I would appreciate any suggestions on how to fix this.
>> 
>> Thank you,
>> Paul
>> 
>> 
>> ___
>> 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

___
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.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Cizmas]

I tried now using libuv 1.35 and it failed again during make at

  CC   src/unix/libuv_la-darwin-proctitle.lo
In file included from 
/System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32:0,
 from 
/System/Library/Frameworks/Security.framework/Headers/Security.h:43,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/CSIdentity.h:43,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:27,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/IconsCore.h:23,
 from 
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:22,
 from 
/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39,
 from 
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:23,
 from src/unix/darwin-proctitle.c:34:
/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7: 
error: variably modified ‘bytes’ at file scope
  char bytes[kAuthorizationExternalFormLength];
   ^
In file included from 
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGContext.h:18:0,
 from 
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGBitmapContext.h:9,
 from 
/System/Library/Frameworks/CoreGraphics.framework/Headers/CoreGraphics.h:11,
 from 
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:35,
 from src/unix/darwin-proctitle.c:34:
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGFont.h:53:40: 
error: initializer element is not constant
 static const CGFontIndex kCGGlyphMax = kCGFontIndexMax;
^~~
In file included from 
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGContext.h:21:0,
 from 
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGBitmapContext.h:9,
 from 
/System/Library/Frameworks/CoreGraphics.framework/Headers/CoreGraphics.h:11,
 from 
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:35,
 from src/unix/darwin-proctitle.c:34:
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGPath.h:391:15: 
error: expected identifier or ‘(’ before ‘^’ token
 typedef void (^CGPathApplyBlock)(const CGPathElement * element);
   ^
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGPath.h:393:53: 
error: unknown type name ‘CGPathApplyBlock’
 CG_EXTERN void CGPathApplyWithBlock(CGPathRef path, CGPathApplyBlock 
CF_NOESCAPE block)
 ^~~~
make: *** [Makefile:2610: src/unix/libuv_la-darwin-proctitle.lo] Error 1


> On Mar 25, 2021, at 10:58 PM, Larry Stone  wrote:
> 
> I’ve been building BIND on MacOS for years (currently on Catalina but has 
> worked on almost the entire Mac OS X series.
> 
>> 
>> On Mar 25, 2021, at 7:50 PM, Paul Cizmas  wrote:
>> 
>> I am new to BIND and I am trying to install version 9.16.13 on a Mac OS X 
>> 10.13.6.
>> 
>> I downloaded version 9.16.13 and, following the suggestions from 
>> https://urldefense.com/v3/__https://krypted.com/mac-os-x/dns-install-bind-macos/__;!!KwNVnqRv!SgN3gnzEKHjO4-cmHIFW1vcyx5KWnm1ii44xUN8Cv7V0BQRszE6xAdIje1bTo8s$
>>  , I am trying to configure using
>> 
>> ./configure --enable-symtable=none --infodir="/usr/share/info" 
>> --sysconfdir="/etc" --localstatedir="/var" --enable-atomic="no" 
>> --with-gssapi=yes --with-libxml2=no
>> 
> 
> I don’t know that site and I don’t know what most of the those options do. A 
> simple ./configure has almost always worked for me.
> 
>> This fails because of libuv
>> 
>> checking for pthread_set_name_np... no
>> checking for pthread_np.h... no
>> checking for libuv... checking for libuv >= 1.0.0... no
>> configure: error: libuv not found
>> 
>> I have libuv installed, however.  It is version 1.41.0.
>> 
> 
> Is libuv where the BIND configure is looking for it? My libuv files are in 
> /usr/local/lib. I have libuv 1.35 (doubt the version is making a difference) 
> and it looks like I installed it a year ago.
> 
> Are you using something like homebrew or macports? I don’t as I was already 
> too established doing everything from scratch when I learned about them. But 
> I believe at least one of them if not both use their own set of directories 
> so something built with one of them will not be found by something coming 
> from the

Re: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Cizmas]

Eddy, I fully agree with you. I wish I could do it.  Unfortunately I failed to 
install libuv from scratch and I took a shortcut by using homebrew (and now I 
am paying for it, as I should).

Paul

> On Mar 25, 2021, at 11:05 PM, Eddy Hahn  wrote:
> 
> I do not use either of them because I cannot trust them. I build all 
> dependencies from scratch so I do not have to depend on others- breaking 
> things from one version to the next.
> Also I do not like to use the old libs shipped with the OS or install 3rd 
> party into the OS directories. 
> 
> Cheers, 
> 
> Eddy
> 
>> On Mar 25, 2021, at 8:59 PM, Larry Stone  wrote:
>> 
>> I’ve been building BIND on MacOS for years (currently on Catalina but has 
>> worked on almost the entire Mac OS X series.
>> 
>>> 
>>> On Mar 25, 2021, at 7:50 PM, Paul Cizmas  wrote:
>>> 
>>> I am new to BIND and I am trying to install version 9.16.13 on a Mac OS X 
>>> 10.13.6.
>>> 
>>> I downloaded version 9.16.13 and, following the suggestions from 
>>> https://urldefense.com/v3/__https://na01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fkrypted.com*2Fmac-os-x*2Fdns-install-bind-macos*2Fdata=04*7C01*7C*7C531de9ed26704038675308d8f00b8f48*7C84df9e7fe9f640afb435*7C1*7C0*7C637523279725421196*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000sdata=wN7nldydRlRxmZrp8rWOtLQQN21cSXnc5x5Ym6oZ5Hs*3Dreserved=0__;JSUlJSUlJSUlJSUlJSUlJSUl!!KwNVnqRv!SeCbRCtQQ1-pyWorY4eIWCDOgRROjaa-_OzHQBubG79Rq8hsFwKYhcS04iT0kFM$
>>>  , I am trying to configure using
>>> 
>>> ./configure --enable-symtable=none --infodir="/usr/share/info" 
>>> --sysconfdir="/etc" --localstatedir="/var" --enable-atomic="no" 
>>> --with-gssapi=yes --with-libxml2=no
>>> 
>> 
>> I don’t know that site and I don’t know what most of the those options do. A 
>> simple ./configure has almost always worked for me.
>> 
>>> This fails because of libuv
>>> 
>>> checking for pthread_set_name_np... no
>>> checking for pthread_np.h... no
>>> checking for libuv... checking for libuv >= 1.0.0... no
>>> configure: error: libuv not found
>>> 
>>> I have libuv installed, however.  It is version 1.41.0.
>>> 
>> 
>> Is libuv where the BIND configure is looking for it? My libuv files are in 
>> /usr/local/lib. I have libuv 1.35 (doubt the version is making a difference) 
>> and it looks like I installed it a year ago.
>> 
>> Are you using something like homebrew or macports? I don’t as I was already 
>> too established doing everything from scratch when I learned about them. But 
>> I believe at least one of them if not both use their own set of directories 
>> so something built with one of them will not be found by something coming 
>> from the other or done from scratch. Those instructions from krypted.com 
>> appear to be doing a “from scratch” version so if you installed libuv with 
>> homebrew or macports, I doubt the krypted.com instructions will find it.
>> 
>> 
>> -- 
>> Larry Stone
>> lston...@stonejongleux.com
>> ___
>> Please visit 
>> https://urldefense.com/v3/__https://na01.safelinks.protection.outlook.com/?url=https*3A*2F*2Flists.isc.org*2Fmailman*2Flistinfo*2Fbind-usersdata=04*7C01*7C*7C531de9ed26704038675308d8f00b8f48*7C84df9e7fe9f640afb435*7C1*7C0*7C637523279725421196*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000sdata=PGVNS*2BEb*2B7YohVLKtzRz30*2F6ls1kvh8ilPQ3Cv57k9Q*3Dreserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!KwNVnqRv!SeCbRCtQQ1-pyWorY4eIWCDOgRROjaa-_OzHQBubG79Rq8hsFwKYhcS0u5MpoDY$
>>   to unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at 
>> https://urldefense.com/v3/__https://na01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.isc.org*2Fcontact*2Fdata=04*7C01*7C*7C531de9ed26704038675308d8f00b8f48*7C84df9e7fe9f640afb435*7C1*7C0*7C637523279725421196*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000sdata=jv*2FCZcukHxDGGXORN3OYGMYp6Utpk*2F*2BYK4ka0sTuHqI*3Dreserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!KwNVnqRv!SeCbRCtQQ1-pyWorY4eIWCDOgRROjaa-_OzHQBubG79Rq8hsFwKYhcS08K2yo00$
>>   for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://urldefense.com/v3/__https://na01.safelinks.protection.outlook.com/?url=https*3A*2F*2Flists.isc.org*2Fmailman*2Flistinfo*2Fbind-users

Re: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Cizmas]

I did use homebrew.  It installed libuv 1.41.0 without any complaints.  Is 
there something I could do to manually point BIND to libuv?

Thank you,
Paul


> On Mar 25, 2021, at 10:12 PM, Mark Andrews  wrote:
> 
> libuv discovery requires pkg-config to be found.  macports/homebrew installs 
> of libuv should register libuv correctly.
> 
> 
>> On 26 Mar 2021, at 11:50, Paul Cizmas  wrote:
>> 
>> Hello:
>> 
>> I am new to BIND and I am trying to install version 9.16.13 on a Mac OS X 
>> 10.13.6.
>> 
>> I downloaded version 9.16.13 and, following the suggestions from 
>> https://urldefense.com/v3/__https://krypted.com/mac-os-x/dns-install-bind-macos/__;!!KwNVnqRv!T2YrsudDg_5xUn4JVLDSFDP1B5SWepbwzT9ay0JLZrWIwZ5iSfh2BCY7WA-Zw5Q$
>>  , I am trying to configure using
>> 
>> ./configure --enable-symtable=none --infodir="/usr/share/info" 
>> --sysconfdir="/etc" --localstatedir="/var" --enable-atomic="no" 
>> --with-gssapi=yes --with-libxml2=no
>> 
>> This fails because of libuv
>> 
>> checking for pthread_set_name_np... no
>> checking for pthread_np.h... no
>> checking for libuv... checking for libuv >= 1.0.0... no
>> configure: error: libuv not found
>> 
>> I have libuv installed, however.  It is version 1.41.0.
>> 
>> I would appreciate any suggestions on how to fix this.
>> 
>> Thank you,
>> Paul
>> 
>> 
>> ___
>> Please visit 
>> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!KwNVnqRv!T2YrsudDg_5xUn4JVLDSFDP1B5SWepbwzT9ay0JLZrWIwZ5iSfh2BCY7SJu0lnU$
>>   to unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at 
>> https://urldefense.com/v3/__https://www.isc.org/contact/__;!!KwNVnqRv!T2YrsudDg_5xUn4JVLDSFDP1B5SWepbwzT9ay0JLZrWIwZ5iSfh2BCY7yy0Nyq0$
>>   for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!KwNVnqRv!T2YrsudDg_5xUn4JVLDSFDP1B5SWepbwzT9ay0JLZrWIwZ5iSfh2BCY7SJu0lnU$
>>  
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

___
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.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Cizmas]

Hello:

I am new to BIND and I am trying to install version 9.16.13 on a Mac OS X 
10.13.6.

I downloaded version 9.16.13 and, following the suggestions from 
https://krypted.com/mac-os-x/dns-install-bind-macos/ 
<https://krypted.com/mac-os-x/dns-install-bind-macos/>, I am trying to 
configure using

./configure --enable-symtable=none --infodir="/usr/share/info" 
--sysconfdir="/etc" --localstatedir="/var" --enable-atomic="no" 
--with-gssapi=yes --with-libxml2=no

This fails because of libuv

checking for pthread_set_name_np... no
checking for pthread_np.h... no
checking for libuv... checking for libuv >= 1.0.0... no
configure: error: libuv not found

I have libuv installed, however.  It is version 1.41.0.

I would appreciate any suggestions on how to fix this.

Thank you,
Paul


___
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

how to stop and remove BIND 9.9.7-P3 on Mac OS X High Sierra 10.13.6?

[Paul Cizmas]

Hello:

I am required by the school’s IT to replace BIND 9.9.7-P3 with 9.16.13.  

I identified that indeed the version running is 9.9.7-P3 by typing “named -v”.

I am totally new to BIND and tried to follow the directions given at 
https://kb.isc.org/docs/aa-00312# <https://kb.isc.org/docs/aa-00312#>.

I tried to stop BIND from running, by typing: 

"sudo service org.isc.named stop"

but it appears that “service” must be replaced by something else because I get:

~$ sudo service org.isc.named stop
Password:
sudo: service: command not found

What should “service” be? 

Is there another command I should issue to stop BIND?

Thank you,
Paul


___
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: lists.isc.org and DMARC

[Paul Kosinski via bind-users]

Our DMARC Policy has been "p=quarantine" since 30 Jun 2019, so I guess it won't 
affect us. (It was "p=none" before that -- we only started using DKIM in Apr 
2017.)


On Tue, 16 Feb 2021 20:54:30 + (UTC)
Dan Mahoney  wrote:

> Greetings bind-users netizens.
> 
> Dan Mahoney, ISC SysAdmin here.
> 
> This is a message about lists.isc.org and DMARC.  If you aren't concerned 
> with DMARC, you can ignore it.  
> 
> Over a year ago, we added adaptations to lists.isc.org to allow mail from 
> DMARC-protected domains to be delivered.
> 
> If you've seen problems with the way lists.isc.org currently handles DMARC 
> (rewriting the From: header if your sending-domain has a restrictive 
> [p=reject or p=quarantine] DMARC policy), we'd like to hear from you at 
> listmas...@isc.org as we are considering making a slightly broader change.
> 
> We are considering setting lists.isc.org to ALSO rewrite the From: header, 
> even if your sending-domain has a DMARC (p=none) policy.  We think this is 
> important because otherwise a domain, in rolling out DMARC with p=none to 
> start, will see false positives from mailing lists (indicating that 
> messages sent via that list would be rejected by the final recipients' 
> mailservers/filters).
> 
> We believe it makes sense for lists.isc.org to behave the same for *ANY* 
> DMARC policy and are considering implementing that in the next few weeks.  
> We will keep you updated here.
> 
> -Dan Mahoney
> ISC

___
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: Problems with interfaces going down

[Paul Kosinski via bind-users]

Would it be possible to use a virtual interface from within bind/named that 
gets mapped by some privileged facility to a hardware interface? (This is the 
sort of thing that VMs have to do all the time.) For example, could a brctl 
bridge help?

Or maybe CAP_NET_BIND_SERVICE would allow the interface to be reactivated (if 
it's a privileged port issue).

Just brainstorming.

Paul


On Fri, 12 Feb 2021 18:33:21 -0500
bindus...@prograde.net wrote:

> Greetings,
> 
> I’ve been fighting a two-fold problem with named (bind 9.16.11) running on 
> macOS.
> 
> 1: If an ethernet interface being listened to drops link, named immediately 
> stops listening to it:
> 
> 12-Feb-2021 17:33:19.326 no longer listening on 192.168.88.220#53
> 
> and
> 
> 2: when link returns I get 2 tries to reestablish listening:
> 
> 12-Feb-2021 17:33:39.458 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:39.463 creating IPv4 interface en1 failed; interface ignored
> 12-Feb-2021 17:33:41.946 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:41.951 creating IPv4 interface en1 failed; interface ignored
> 
> which both fail because named is no longer running as root.
> 
> --
> 
> Where I’m confused is that this ISC KB article:
> 
> https://kb.isc.org/docs/aa-00420
> 
> seems to imply that the "no longer listening" event is due to a periodic 
> interface scan finding the interface "unavailable".
> 
> That doesn’t fit my observations since it happens as soon as link is lost. If 
> some minutes-long periodic scan were needed to detect the interface being 
> down it would take, on average, half of that period to happen. It does not.
> 
> Further, I tried what the KB article advised by adding the option:
> 
>   interface-interval 0;
> 
> That does seem to stop the periodic scan (since my log is no longer filled 
> with errors) but the “no longer listening” event still occurs right when the 
> interface drops.
> 
> --
> 
> Is it not possible to have named drop to a non-root user (via -u) but still 
> recover from (or ride through) a momentary ethernet link loss?
> 
> Having the server stop working due to a switch I have no control over burping 
> is very suboptimal.
> 
> Thanks for any ideas.
> 
>
___
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.11 serving up false answers for a single domain.

[Paul Kosinski via bind-users]

I don't think tcpdump was installed by default with various versions of Debian 
that I set up in the last few years for networking. I didn't bother to install 
it, as it's output is different enough (old fashioned?) from the sharks to be 
annoying. It *was* installed with OpenSuSE 15.2 though. (OpenSuSE 15.2 -- the 
"stable" release that wants you to update something every day.)


On Fri, 12 Feb 2021 00:35:53 +
"John W. Blue via bind-users"  wrote:

> Most people like yourself that do not care about OS purity often are not 
> obligated (granted super broad generalization) to explain their changes to an 
> Enterprise Change Management Board (ECMB or similar) for deviations from a 
> "standard image".
> 
> That is also 100% okay too.  Those types of shops/sysadmins also typically 
> don't have a buckets of cash sitting around either so you work with makes 
> sense and use the resources available to get it done.
> 
> The over-arching point is that the lowest common denominator for proper 
> troubleshooting is that tcpdump is useful and it does not need to be sourced 
> or installed.  It is ready to go out of the box for nearly all situations 
> that could potentially be encountered.
> 
> Usually. 
> 
> Murphy's law of unintended consequences should always be account for.
> 
> John
___
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.11 serving up false answers for a single domain.

[Paul Kosinski via bind-users]

I rather prefer tshark to tcpdump: it's essentially the command line version of 
wireshark, and thus has wireshark's protocol "dissecting" abilities.


On Wed, 10 Feb 2021 22:20:08 +
"John W. Blue via bind-users"  wrote:

> Three words:  tcpdump and wireshark
> 
> It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and 
> flow .. pen and paper .. I could go on but …
> 
> Know them.  Love them.  They are your newest best friends.
> 
> 
> 
> Using tcpdump IMHO should be the first tool anyone uses when troubleshooting 
> seemly unexplainable DNS weirdness.
> 
> Knowing what is being put on the wire (or lack thereof) is critical since it 
> provides key factual data points that decisions can be made on.  When running 
> tcpdump on the DNS server I personally prefer this command:
> 
> tcpdump -n -i  -s 65535 -w 
> 
> dash n is telling tcpdump that you do not want it to resolve hostnames.  This 
> is an important option when doing DNS troubleshooting because you do not want 
> extra resolutions taking place.
> dash s is saying gimme the full packet.
> dash w is the name of the file you want the output saved in.
> 
> After starting the command, run several queries from a host and ctrl+c to 
> exit.
> 
> Once you get your file into wireshark now you can start slicing n dicing on 
> the data!
> 
> Here is handy wireshark filter:  dns.qry.name == internet-dns1.state.ma.us
> 
> By using a filter of dns.flags.rcode == (number here) you can drive off into 
> the weeds and get super granular with sorting the data.  For example 
> “dns.flags.rcode == 2” will show you all of the server failures for queries.
> 
> It is hard to provide further guidance on what to do since what you find in 
> the pcap is only a starting point.
> 
> Good hunting!
> 
> As an aside I would like to mention that you do not need to travel home to 
> get situational awareness when the diggui.com website can be used instead.
> 
> Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?
> 
> https://dnsviz.net/d/state.ma.us/dnssec/
> 
> John
___
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.11 serving up false answers for a single domain.

[Paul Kosinski via bind-users]

Do you know about mxtoolbox.com? It (and other similar sites) does a good job 
of diagnosing DNS-related problems. I use it now and then to check out my own 
sites, as it gives a "second opinion".

In particular its "DNS Lookup' function reported the following for 
"internet-dns1.state.ma.us"

  Type  Domain Name IP Address  TTL
  A internet-dns1.state.ma.us   170.63.70.3615 min
  ...
  Reported by internet-dns3.state.ma.us on 2/9/2021 at 10:44:08 PM (UTC -6), 
just for you.


But its "DNS Check" function them reported

  dns:internet-dns1.state.ma.us  
  No Results Found
  ...
  Reported by internet-dns2.state.ma.us on 2/9/2021 at 10:51:04 PM (UTC -6)

and later

  ...
  Reported by internet-dns3.state.ma.us on 2/9/2021 at 10:54:13 PM (UTC -6)

Strange indeed: sounds like they have problems.



On Tue, 9 Feb 2021 22:50:19 -0500
"sami's strat"  wrote:

> Thanks Mark.
> 
> However, the traceroute to the hostnamed failed for the same reason.
> Please note:
> 
> [root@myhost data]# dig internet-dns1.state.ma.us
> 
> 
> 
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us
> 
> ;; global options: +cmd
> 
> ;; Got answer:
> 
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641
> 
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> 
> 
> ;; OPT PSEUDOSECTION:
> 
> ; EDNS: version: 0, flags:; udp: 4096
> 
> ;; QUESTION SECTION:
> 
> ;internet-dns1.state.ma.us. IN  A
> 
> 
> 
> ;; Query time: 1263 msec
> 
> ;; SERVER: 192.168.33.12#53(192.168.33.12)
> 
> ;; WHEN: Tue Feb 09 22:34:15 EST 2021
> 
> ;; MSG SIZE  rcvd: 54
> 
> 
> 
> [root@myhost data]# dig internet-dns1.state.ma.us +trace
> 
> 
> 
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us
> +trace
> 
> ;; global options: +cmd
> 
> .   516485  IN  NS  c.root-servers.net.
> 
> .   516485  IN  NS  e.root-servers.net.
> 
> .   516485  IN  NS  f.root-servers.net.
> 
> .   516485  IN  NS  l.root-servers.net.
> 
> .   516485  IN  NS  m.root-servers.net.
> 
> .   516485  IN  NS  d.root-servers.net.
> 
> .   516485  IN  NS  g.root-servers.net.
> 
> .   516485  IN  NS  k.root-servers.net.
> 
> .   516485  IN  NS  b.root-servers.net.
> 
> .   516485  IN  NS  h.root-servers.net.
> 
> .   516485  IN  NS  a.root-servers.net.
> 
> .   516485  IN  NS  i.root-servers.net.
> 
> .   516485  IN  NS  j.root-servers.net.
> 
> .   516485  IN  RRSIG   NS 8 0 518400
> 202103 2021020922 42351 .
> QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f
> mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w
> SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG
> NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb
> q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK
> N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA==
> 
> ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms
> 
> 
> 
> us. 172800  IN  NS  a.cctld.us.
> 
> us. 172800  IN  NS  b.cctld.us.
> 
> us. 172800  IN  NS  c.cctld.us.
> 
> us. 172800  IN  NS  e.cctld.us.
> 
> us. 172800  IN  NS  f.cctld.us.
> 
> us. 172800  IN  NS  k.cctld.us.
> 
> us. 86400   IN  DS  21364 8 1
> 260D0461242BCF8F05473A08B05ED01E6FA59B9C
> 
> us. 86400   IN  DS  21364 8 2
> B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
> 
> us. 86400   IN  RRSIG   DS 8 1 86400 202103
> 2021020922 42351 .
> rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/
> VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd
> viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ
> D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj
> ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR
> x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA==
> 
> ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms
> 
> 
> 
> state.ma.us.7200IN  NS  internet-dns3.state.ma.us.
> 
> state.ma.us.7200IN  NS  internet-dns1.state.ma.us.
> 
> state.ma.us.7200IN  NS  internet-dns2.state.ma.us.
> 
> state.ma.us.3600IN  DS  47628 7 2
> 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
> 
> state.ma.us.3600IN  DS  41388 7 1
> 36D899932AF794EADD671161515E48FE829BB7FE
> 
> state.ma.us.  

Re: Scripting dnssec-verify - processing command output

[Paul Kosinski via bind-users]

It sounds to me like dnssec-verify is sending the output in question to STDERR 
instead of STDOUT.


On Sat, 06 Feb 2021 19:02:28 +
Matthew Richardson  wrote:

> I have been using Perl to do a reasonable amount of scripting, running bind
> utilities and processing the results into variables.  The details below are
> from Bind 9.11.27 on Centos 7.
> 
> The code:-
> 
> $resp = `dig -t soa example.com`;
> print "dig resp:'$resp'\n";
> 
> gets the result of the dig command into the variable $resp and prints it.
> 
> However:-
> 
> $resp = `dnssec-verify -I text -o example.com example.com.zone`;
> print "dnssec-verify resp:'$resp'\n";
> 
> displays the results of the dnssec-verify command on the console and leaves
> the variable $resp empty.
> 
> Any ideas would be appreciated...
> 
> As an aside, using dnssec-keygen DOES put the results into the variable.
> 
> Best wishes,
> Matthew
___
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: Two copies of recent posts

[Paul Kosinski via bind-users]

Yes indeed: I sent the last email (and this one) to bind-users and CC-ed to 
you. That explains why there are two different ESMTP IDs.

The question is, have you, like I have, received two copies of any emails (from 
lists.isc.org) where there *identical* ESMTP IDs in their associated sequences 
of "Received:" headers. This would indicate that the duplication was caused by 
an intermediate MTA. (The one I previously indicated was mx.pao1.isc.org, which 
is the one and only MX for lists.isc.org.)

-Paul K.




On Tue, 24 Nov 2020 22:46:06 -0500
Jim Popovitch via bind-users  wrote:

> On Tue, 2020-11-24 at 22:22 -0500, Paul Kosinski wrote:
> > My reading of the headers (below) does *not* suggest "Reply All".
> > 
> > Rather, they show that mx.pao1.isc.org sent/forwarded the email once,
> > and it was received by lists.isc.org once with ESMTP ID 026B967ED73.
> > But then lists.isc.org resent/forwarded it more than once, as it was
> > received a few seconds later by lists.isc.org (again!) with two
> > *different* ESMTP IDs: B380C67F367 and E414B67F36E.
> > 
> > This suggests to me that lists.isc.org is being a bit too diligent in
> > delivering its email.
> >   
> 
> I just received 2 copies of your post, with 2 different ESMTP IDs...
> because you sent it to 2 different recipients.  That same thing would
> happen if you sent it to bind-users@lists.isc.org and 
> bind-users@lists.isc.org.
> 
> -Jim P.
>
___
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: Two copies of recent posts

[Paul Kosinski via bind-users]

My reading of the headers (below) does *not* suggest "Reply All".

Rather, they show that mx.pao1.isc.org sent/forwarded the email once,
and it was received by lists.isc.org once with ESMTP ID 026B967ED73.
But then lists.isc.org resent/forwarded it more than once, as it was
received a few seconds later by lists.isc.org (again!) with two
*different* ESMTP IDs: B380C67F367 and E414B67F36E.

This suggests to me that lists.isc.org is being a bit too diligent in
delivering its email.



On Sun, 22 Nov 2020 22:58:07 -0500
Jim Popovitch via bind-users  wrote:

> On Sun, 2020-11-22 at 21:56 -0500, Paul Kosinski via bind-users wrote:
> > I've been getting two identical copies of recent posts to this list...  
> 
> Me too, but it's because of people hitting reply-all thinking that they
> are replying to the list and the poster.  People really need to verify
> who they are replying to, it's easy to see from the "Servfail on Bind
> -9.16.1" thread where the problem(s) exist.
> 
> Note Paul, I only received one copy of your post, and you should be only
> receiving one copy of my reply.
> 
> -Jim P.


-
Received: from iment0.iment.com (localhost [127.0.0.1])
by imes.imemail.iment.com (Postfix) with ESMTP id B72843283403
for ; Sun, 22 Nov 2020 18:48:18 -0500 (EST)
Received: from lists.isc.org (lists.isc.org [149.20.1.60])
by iment0.iment.com (Postfix) with ESMTP id 7B3C3607948F
for ; Sun, 22 Nov 2020 18:48:18 -0500 (EST)
Received: from lists.isc.org (localhost [127.0.0.1])
by lists.isc.org (Postfix) with ESMTP id B380C67F367;
Sun, 22 Nov 2020 23:47:27 + (UTC)
X-Original-To: bind-users@lists.isc.org
Delivered-To: bind-users@lists.isc.org
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53])
 by lists.isc.org (Postfix) with ESMTP id 026B967ED73;
 Sun, 22 Nov 2020 23:47:23 + (UTC)
-
Received: from iment0.iment.com (localhost [127.0.0.1])
by imes.imemail.iment.com (Postfix) with ESMTP id EDA193283403
for ; Sun, 22 Nov 2020 18:48:27 -0500 (EST)
Received: from lists.isc.org (lists.isc.org [149.20.1.60])
by iment0.iment.com (Postfix) with ESMTP id B3A43607948F
for ; Sun, 22 Nov 2020 18:48:27 -0500 (EST)
Received: from lists.isc.org (localhost [127.0.0.1])
by lists.isc.org (Postfix) with ESMTP id E414B67F36E;
Sun, 22 Nov 2020 23:47:27 + (UTC)
X-Original-To: bind-users@lists.isc.org
Delivered-To: bind-users@lists.isc.org
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53])
 by lists.isc.org (Postfix) with ESMTP id 026B967ED73;
 Sun, 22 Nov 2020 23:47:23 + (UTC)
--

___
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

Two copies of recent posts

[Paul Kosinski via bind-users]

I've been getting two identical copies of recent posts to this list
(such as this item). This only started happening in the past 24 hours
or so. Is anyone else seeing this?

Upon examination of the headers of the two copies, it looks like ISC's
list-servers are doing the duplication. 

(The first part of the actual message follows the headers.)

-
Received: from iment0.iment.com (localhost [127.0.0.1])
by imes.imemail.iment.com (Postfix) with ESMTP id B72843283403
for ; Sun, 22 Nov 2020 18:48:18 -0500 (EST)
Received: from lists.isc.org (lists.isc.org [149.20.1.60])
by iment0.iment.com (Postfix) with ESMTP id 7B3C3607948F
for ; Sun, 22 Nov 2020 18:48:18 -0500 (EST)
Received: from lists.isc.org (localhost [127.0.0.1])
by lists.isc.org (Postfix) with ESMTP id B380C67F367;
Sun, 22 Nov 2020 23:47:27 + (UTC)
X-Original-To: bind-users@lists.isc.org
Delivered-To: bind-users@lists.isc.org
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53])
 by lists.isc.org (Postfix) with ESMTP id 026B967ED73;
 Sun, 22 Nov 2020 23:47:23 + (UTC)
-
Received: from iment0.iment.com (localhost [127.0.0.1])
by imes.imemail.iment.com (Postfix) with ESMTP id EDA193283403
for ; Sun, 22 Nov 2020 18:48:27 -0500 (EST)
Received: from lists.isc.org (lists.isc.org [149.20.1.60])
by iment0.iment.com (Postfix) with ESMTP id B3A43607948F
for ; Sun, 22 Nov 2020 18:48:27 -0500 (EST)
Received: from lists.isc.org (localhost [127.0.0.1])
by lists.isc.org (Postfix) with ESMTP id E414B67F36E;
Sun, 22 Nov 2020 23:47:27 + (UTC)
X-Original-To: bind-users@lists.isc.org
Delivered-To: bind-users@lists.isc.org
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53])
 by lists.isc.org (Postfix) with ESMTP id 026B967ED73;
 Sun, 22 Nov 2020 23:47:23 + (UTC)
--


On Mon, 23 Nov 2020 10:47:20 +1100
Mark Andrews  wrote:

> Ok.  Lets start by debugging this from the trust anchor downwards.
> Lets see what "dig +dnssec +cd dnskey .” returns.  It should return
> something like below with 2 DNSKEY records and a RRSIG for the DNSKEY.
> The RRSIG is regenerated daily so it will likely differ.  The DNSKEY
> records should be a exact match.  In this case flags contains ‘ad’ which
> means that the RRset has previously been validated.

> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users  
> 
___
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: How can I launch a private Internet DNS server?

[Paul Kosinski via bind-users]

With regard to using chroot, hasn't named/BIND long had the "-u" (user)
and "-t" (directory) options to accomplish the same thing more easily?


On Fri, 16 Oct 2020 12:47:35 -0500
Chuck Aurora  wrote:

> /me catching up on earlier parts of this thread,
> 
> On 2020-10-15 11:42, alcol alcol wrote:
> > A DNS server can exist if you follow NIC instractions.
> >  Mainly have you a leased line ever on? primary DNS can't be down or
> > NIC could down your domain.
> >  Then you have to install and configure it. Better a fedora core , and  
> 
> I'm not sure what all that means (language barrier, perhaps), but I
> have some gripes with what I do understand.
> 
> First, re: Fedora, no one distro/OS can truly claim to be best.  The
> best advice to a beginner is to choose one and to learn it very well.
> Fedora can be a good choice, as can other GNU/Linux distros, as also
> can be various *BSD flavors.  The point is: it depends what the user
> is comfortable to manage.
> 
> > CHROOT, DNS is one of the services more targeted to enter inside a
> > system.  
> 
> False.  A chroot is a fine idea if you know how to set it up and to
> maintain it, but it is certainly not a requirement for a beginner.  A
> beginner in BIND (as in anything else) will do best by starting simple
> and building on what is learned.
> 
> Also, while DNS is indeed a target of abuse, I honestly cannot recall
> a single exploit of BIND 9 that would lead to system penetration.  It
> is true that BIND's named has had more than its share of security
> issues and bugs, but TTBOMK all of these have been crashes, causing
> only denial of service.
___
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: Deconstructing the Great Firewall of China

[Paul Kosinski via bind-users]

The article is from 2016, probably before DNSSEC become so widespread.
But I would guess that their current overall approach is not a radical
departure from what was outlined in the article.


On Tue, 23 Jun 2020 13:41:18 +0200
Alessandro Vesely  wrote:

> On 2020-06-05 9:29 p.m., Paul Kosinski via bind-users wrote:
> > A very interesting article on how China uses DNS (among other things)
> > to "control" Internet usage.
> > 
> > https://blog.thousandeyes.com/deconstructing-great-firewall-china/  
> 
> 
> The term "DNSSEC" appears just once in that article, after the
> picture.  Yet, maps[*] show China as a fully operational country in
> that respect.
> 
> [*] https://www.dnssec-deployment.org/tag/maps/
> 
> Best
> Ale
___
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

Deconstructing the Great Firewall of China

[Paul Kosinski via bind-users]

A very interesting article on how China uses DNS (among other things)
to "control" Internet usage.

https://blog.thousandeyes.com/deconstructing-great-firewall-china/
___
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: TSIG DDNS and windows clients

[Paul Ebersman]

rharolde> Thanks for the link. Lots of pieces to get working there. Not
rharolde> nearly as simple as TSIG. But good if you are already using
rharolde> Kerberos.

MS active directory is kerberos under the hood. You don't need to run a
classic mit/hesiod KDC to get GSS-TSIG to work. But it is cryptic and a
pain.
___
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

Re: DoH plugin for BIND

[Paul Kosinski via bind-users]

I wasn't complaining about port 25, I was just citing it as a
counterexample to the claim that ISPs "must" pass all traffic.

I think that most ISPs tell customers how to set up their email clients
(NUAs) including what port to use. Of course it seems that now most
people use Web based email like Gmail, Yahoo (and even Comcast/Xfinity)
so they never see port numbers.


On Sat, 2 May 2020 15:51:58 +0200
Reindl Harald  wrote:

> Am 02.05.20 um 15:41 schrieb Michael De Roover:
> > In my experience and from what I've heard, very few.   
> 
> if that would be true how comes that most mail clients still default to
> 25 for submission and years after closing port 25 on our mailserver i
> still struggle with customers smartphones still not using 587?
> 
> in fact 10 years ago some ISP's *tried* to kill outbound port 25 because
> there is no point in using it from a homemachine and at that time we
> struggeled also to explain our customers that 25 is plain wrong
> 
> finally they gave up because the damage of open port 25 is killed with
> dnsbl but the customer support went crazy with "why can't i send email
> with my internet connection"
> 
> > Even if your ISP allows it, chances are that other mail servers will reject 
> > it  
> 
> that's a completl different story
> 
> > On 5/2/20 3:30 PM, Paul Kosinski via bind-users wrote:  
> >> How many ISPs allow traffic on port 25? My impression is that even many
> >> (non-enterprise) business customers can't use port 25  
___
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

Re: DoH plugin for BIND

[Paul Kosinski via bind-users]

How many ISPs allow traffic on port 25? My impression is that even many
(non-enterprise) business customers can't use port 25.


On Sat, 2 May 2020 09:28:54 +0200
Reindl Harald  wrote:

> Am 02.05.20 um 09:00 schrieb Michael De Roover:
> > That's actually my biggest concern with DoH, ISP blocking. It doesn't
> > seem as obvious as it is with DoT, but deep packet inspection (DPI) is
> > already a thing. Don't expect an ISP that wants to block DoT to not
> > (want to) block DoH either. The crux of the problem at that point is not
> > the technology, it is the ISP's incentives. If the ISP wants to block
> > DoT for whatever reason, personally I'd consider it.. not exactly fine
> > but at least their right to do so. That's their decision to make.   
> 
> seriously?
> 
> that seems to be some US attitude, no wonder what happens there with
> user attitudes like "but at least their right to do so"
> 
> the ISP by definition has exactly one right: get money for his service
> which is described as "route and transfer every package, don't look at
> it, don't mangle it, you have no business about the content of my traffic"
___
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

Re: Problem to transfer reverse zone DNS on secondary DNS servers

[Paul Kosinski via bind-users]

I was pleased that I was able to get our two (successive) ISPs to set
up reverse DNS for our small number of IP addresses, and each twice to
change them when they moved us to moved us to new IP ranges (due to the
IPv4 crunch). It never even occurred to me that it might be possible to
have them delegated to our DNS server (which could handle it, being
BIND running native on a Linux VM on their hardware -- no "helpful"
ISP mandated interface software to interfere with configuration). 

P.S. Unfortunately our 2 current IPs, although adjacent, are not /31,
and thus would require 2 delegations


On Fri, 27 Dec 2019 13:40:11 -0700
Grant Taylor via bind-users  wrote:

> On 12/27/19 1:22 PM, Reindl Harald wrote:
> > nobody out there will delegate single /255 ip's
> 
> I've had multiple different ISP's delegate reverse DNS for single IPs 
> (/32 or /128) multiple times.
> 
> Some used RFC 2317 Classless IN-ADDR.ARPA Delegation, others used 
> standard delegation.
> 
> Some ~> many ~> maybe most will not delegate in any way.  But enough 
> have done so (repeatedly) to definitely NOT be able to say nobody
> will delegate.
___
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

Peculiar DNS queries

[Paul Kosinski via bind-users]

Every so often, we get a run of peculiar queries to our (BIND / named)
DNS server. Note the apparently random mix of lower case and upper case
letters in the domain names.

Does anybody have any idea why somebody would be doing this? (It's
legal, I guess, but quite non-standard.)

Dec 22 12:05:43 iment0 named[10333]: client 134.0.217.68#20012 (Www.IMent.coM): 
query: Www.IMent.coM IN  -E (216.55.100.246)

Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.54#53150 (Www.iMent.Com): 
query: Www.iMent.Com IN  -E (216.55.100.246)

Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.53#27016 (WWw.imENT.cOm): 
query: WWw.imENT.cOm IN A -E (216.55.100.245)

Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.69#23417 (WWw.IMeNt.cOM): 
query: WWw.IMeNt.cOM IN A -E (216.55.100.245)

Thanks,
Paul Kosinski
___
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

Re: Zoneformat

[Paul Kosinski via bind-users]

"... long ago adapted to using full numbers, including area codes, for
pretty much *all* phone dialing ..."

Except that that proved to be so onerous that people often use "speed
dialing" for commonly dialed numbers. (Not to mention the fact that
people usually address their friends and coworkers by short names.)


On Mon, 28 Oct 2019 12:19:35 -0400
Kevin Darcy  wrote:

> [ Classification Level: PUBLIC ]
> 
> My opinion? It's better to wean your users away from shortnames than
> to try to cobble together kludges, on the client side or the BIND
> side, to support a bad habit. Shortnames introduce ambiguity, lead to
> nasty surprises, are inefficient and insecure. Just like we (in the
> U.S. at least) long ago adapted to using full numbers, including area
> codes, for pretty much *all* phone dialing, people can adapt to using
> FQDNs. They've already adapted to it, overwhelmingly, for Internet
> web traffic (notwithstanding some "helpful" browsers that will tack
> on "www" to the front of a shortname, and ".com" at the end, which is
> often *not* what is wanted or safe). Why have a different user
> experience, when on or off the enterprise network, a perimeter that
> is quickly eroding? Just use FQDNs everywhere, keep it consistent.
> 
> Anyway, that's my 2-cents, from someone who has been battling the
> "shortname disease" for decades, with a substantial amount of
> (although not perfect) success.
> 
> 
>   - Kevin
> 
> On Mon, Oct 28, 2019 at 8:56 AM MEjaz  wrote:
> 
> > Noxexistent domain error .
> >
> > Here is my configuration.
> > ===
> >
> > zone "crm365app" {
> > type master;
> > file "crm365app.cyberia.net.sa.hosts";
> > allow-query {any;};
> > };
> >
> >
> > File
> >
> > 
> > [root@ns1 ~]# cat  /var/named/crm365app.cyberia.net.sa.hosts
> > $TTL 3600
> > ;   Addresses and other host information
> > ;
> > ;
> >
> > @   IN  SOA ns1.cyberia.net.sa. root.cyberia.net.sa. (
> > 2015034459 ; serial
> > 43200   ; refresh every 12 hours
> > 4320; retry after 1 hour
> > 1209600  ; expire after 2 weeks
> > 21600 )  ; minimum
> >
> > ; Define the name servers and mail servers
> >
> > IN  NS  ns1.cyberia.net.sa.
> > IN  NS  ns2.cyberia.net.sa.
> >
> > IN  MX  10 smtp.cyberia.net.sa.
> >
> > ; Define localhost
> > *INA   127.0.0.1
> >
> > ; Define hosts in this zone
> >
> >
> > www IN  CNAME   webhost.cyberia.net.sa.
> > crm365app   IN  A   212.71.33.252
> >
> > =zone file
> > end=
> >
> > [root@ns1 named]# host crm365app
> > Host crm365app not found: 3(NXDOMAIN)
> >  [root@ns1 named]# named-checkzone crm365app
> > crm365app.cyberia.net.sa.hosts
> > zone crm365app/IN: loaded serial 2015034459
> > OK
> >
> > -Original Message-
> > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On
> > Behalf Of Reindl Harald
> > Sent: Monday, October 28, 2019 1:46 PM
> > To: bind-users@lists.isc.org
> > Subject: Re: Zoneformat
> >
> >
> >
> > Am 28.10.19 um 11:01 schrieb MEjaz:
> > > *From:* MEjaz [mailto:me...@cyberia.net.sa]
> > > *Sent:* Monday, October 28, 2019 10:27 AM
> > > *To:* 'bind-users-boun...@lists.isc.org'
> > > 
> > > *Subject:* Zoneformat
> > >
> > > Is ther any way I can create the zone without the (.) I mean non
> > > fully qualified domain name just as "example" instead
> > > "example.com"'
> >
> >
> > what is the problem you try to solve?
___
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

Re: search and ndots support in bind utilities

[Paul Kosinski via bind-users]

Following https://www.icann.org/en/system/files/files/sac-064-en.pdf,
it sounds like modest groups of Internet users (such as informal clubs)
that don't have their own official domain (like "iment.com") are out of
luck if they would like to have local subdomains -- unless they want to
use the quite misleading reserved TLD "test", that is.

It's really too bad that the committee that expanded the space of TLDs
weren't as farsighted as those who allocated the IPv4 addresses to
include non-routable ones for local (intra-LAN) use.

P.S. Note that the domain implied by the PTR lookup result of such a
group's external IP address, although unique, is usually not suitable.
Most can change without notice due to DHCP, and they also tend to be
something unworkable, like "c-66-31-152-1.hsd1.ma.comcast.net.".


On Mon, 30 Sep 2019 09:35:57 -0600
Paul Ebersman  wrote:

> pemensik> I am aware search is a no-no in DNS community. However, is
> pemensik> there any public documentation to this change? Is there RFC
> pemensik> recommending not to use search or how it should be used,
> pemensik> related to today's top level domains?
> 
> pemensik> While I agree it is dangerous, there are still people using
> pemensik> it. I think we should point them at some document,
> pemensik> explaining what are possible dangers. How to use it safe
> pemensik> way or how to avoid using it at all.
> 
> See ICANN SSAC doc 64:
> 
>   <https://www.icann.org/en/system/files/files/sac-064-en.pdf>
> 
> It goes into detail on why search/suffix lists are a bad idea.
___
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

Re: search and ndots support in bind utilities

[Paul Ebersman]

pemensik> I am aware search is a no-no in DNS community. However, is
pemensik> there any public documentation to this change? Is there RFC
pemensik> recommending not to use search or how it should be used,
pemensik> related to today's top level domains?

pemensik> While I agree it is dangerous, there are still people using
pemensik> it. I think we should point them at some document, explaining
pemensik> what are possible dangers. How to use it safe way or how to
pemensik> avoid using it at all.

See ICANN SSAC doc 64:

  

It goes into detail on why search/suffix lists are a bad idea.
___
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

DMARC test

[Paul Kosinski via bind-users]

Testing how lists.isc.org handles DMARC "Quarantine" (and "Reject")
policy. The enterpr...@mozilla.org mailing list forwards such email in a
way that some recipients choke on it (i.e., can't validate it).
___
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

Re: Barclays bank domain unresolvable only on some servers

[Paul Kosinski]

A *bank* not using DNSSEC??  Glad I don't have any money there.



On Sun, 16 Jun 2019 14:00:36 +0100 (BST)
"G.W. Haywood via bind-users"  wrote:

> Hi there,
> 
> On Sun, 16 Jun 2019, Mark Andrews wrote:
> 
> > The servers for this zone are broken, they do not respond to
> > queries with DNS COOKIE options present.  You can add server
> > options to named.conf to work around this while Barclays fix their
> > servers / firewalls.  Modern recursive servers are no longer
> > working around broken servers that do not respond to queries.  See
> > DNS flag day.  It looks like Barclays ignored the messages.
> 
> They have some history of ignoring messages:
> 
> $ whois barclays.com | grep DNSSEC
> DNSSEC: unsigned
> 
___
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

RE: dns latency

[Paul A]

Bob,

I get no real latency doing this, previously I was pinging the GTLD with the 
high latency from the query and I was not seeing any latency with ping, thus 
why I emailed the list.
Currently doing a dig +trace on comcast.net sees no issues, but per my emails 
below, there was high latency from the GLTD to comcast’s DNS I even got, dig: 
couldn't get address for 'dns101.comcast.net': no more at one point. Although 
now it seems to be back to normal, not sure what to make of it. 

 Thanks for your reply Bob.

Paul 


 a 
;; Query time: 26 msec
 b 
;; Query time: 172 msec
 c 
;; Query time: 26 msec
 d 
;; Query time: 26 msec
 e 
;; Query time: 76 msec
 f 
;; Query time: 76 msec
 g 
;; Query time: 75 msec
 h 
;; Query time: 8 msec
 i 
;; Query time: 8 msec
 j 
;; Query time: 8 msec
 k 
;; Query time: 38 msec
 l 
;; Query time: 38 msec
 m 
;; Query time: 38 msec

From: Bob Harold [mailto:rharo...@umich.edu] 
Sent: Friday, April 12, 2019 12:52 PM
To: Paul A 
Cc: Mark Andrews ; bind-users@lists.isc.org 
Subject: Re: dns latency


On Fri, Apr 12, 2019 at 12:37 PM Paul A  wrote:
Mark, per my previous email, this high latency only happens when digging for
Comcast. I  did not compile bind on this machine, I'm using the latest Bind
package that came with CentOS 7, bind-chroot-9.9.4-73.el7_6.x86_64. Looking
at the changelog for the RPM it doesn't mention any issue with dig and
latency and I assume this has been patched by Redhat at some point.  

I just wanted to verify that what Im seeing with Comcast is somehow not
related to only me and someone else is seeing this issue.  The lastest dig I
did came back with  
"dig: couldn't get address for 'dns101.comcast.net': no more" so I doubt
it's a dig version issue. 

Paul 


;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms

net.172800  IN  NS  k.gtld-servers.net.
net.172800  IN  NS  b.gtld-servers.net.
net.172800  IN  NS  l.gtld-servers.net.
net.172800  IN  NS  a.gtld-servers.net.
net.172800  IN  NS  m.gtld-servers.net.
net.172800  IN  NS  c.gtld-servers.net.
net.172800  IN  NS  i.gtld-servers.net.
net.172800  IN  NS  e.gtld-servers.net.
net.172800  IN  NS  d.gtld-servers.net.
net.172800  IN  NS  g.gtld-servers.net.
net.172800  IN  NS  h.gtld-servers.net.
net.172800  IN  NS  j.gtld-servers.net.
net.172800  IN  NS  f.gtld-servers.net.
net.86400   IN  DS  35886 8 2
7862B27F5F516EBE196804
44D4CE5E762981931842C465F00236401D 8BD973EE
net.86400   IN  RRSIG   DS 8 1 86400 2019042505
2019
041204 25266 . Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx
eU1c
rjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt
hguq+9jcNTMAzrUXvi6Tb8oTb36
lprYIfg21yO1d8RO6cx3L0dJMcuez
WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71An
MV+nob 48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J
NkegEfRCzRZYYKiD
MwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ==
;; Received 1168 bytes from 199.9.14.201#53(b.root-servers.net) in 88 ms

comcast.net.172800  IN  NS  dns101.comcast.net.
comcast.net.172800  IN  NS  dns102.comcast.net.
comcast.net.172800  IN  NS  dns103.comcast.net.
comcast.net.172800  IN  NS  dns104.comcast.net.
comcast.net.172800  IN  NS  dns105.comcast.net.
comcast.net.86400   IN  DS  40909 5 2
30C0F50E68DCC9A2F279A9
94C07CF22CED97AADF44C2B1FE38A1B32B A1A34174
comcast.net.86400   IN  DS  40909 5 1
DDC19733884EE533B35B4B
57717BEA9B0EF2C4D1
comcast.net.86400   IN  RRSIG   DS 8 2 86400 20190417054136
2019
0410043136 51638 net.
l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f X
zNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ
yTAq2wPMGD6evSUSDLfqYu8h
oJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk=
dig: couldn't get address for 'dns101.comcast.net': no more

-Original Message-
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Friday, April 12, 2019 11:20 AM
To: Paul A 
Cc: bind-users@lists.isc.org 
Subject: Re: dns latency

Before you pay attention to the round trip time you need this fix from BIND
9.9.6 from nearly 5 years ago now (2014-07-31).

3903.  [bug]   Improve the accuracy of DiG's reported round trip
   time. [RT 36611]

Mark

> On 13 Apr 2019, at 12:59 am, Paul A  wrote:
> 
> This is not really a Bind issue, but can anyone else confirm latency 
> when querying Comcast from the root down? I ask because this morning  some

RE: dns latency

[Paul A]

Mark, per my previous email, this high latency only happens when digging for
Comcast. I  did not compile bind on this machine, I'm using the latest Bind
package that came with CentOS 7, bind-chroot-9.9.4-73.el7_6.x86_64. Looking
at the changelog for the RPM it doesn't mention any issue with dig and
latency and I assume this has been patched by Redhat at some point.  

I just wanted to verify that what Im seeing with Comcast is somehow not
related to only me and someone else is seeing this issue.  The lastest dig I
did came back with  
"dig: couldn't get address for 'dns101.comcast.net': no more" so I doubt
it's a dig version issue. 

Paul 


;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms

net.172800  IN  NS  k.gtld-servers.net.
net.172800  IN  NS  b.gtld-servers.net.
net.172800  IN  NS  l.gtld-servers.net.
net.172800  IN  NS  a.gtld-servers.net.
net.172800  IN  NS  m.gtld-servers.net.
net.172800  IN  NS  c.gtld-servers.net.
net.172800  IN  NS  i.gtld-servers.net.
net.172800  IN  NS  e.gtld-servers.net.
net.172800  IN  NS  d.gtld-servers.net.
net.172800  IN  NS  g.gtld-servers.net.
net.172800  IN  NS  h.gtld-servers.net.
net.172800  IN  NS  j.gtld-servers.net.
net.172800  IN  NS  f.gtld-servers.net.
net.86400   IN  DS  35886 8 2
7862B27F5F516EBE196804
44D4CE5E762981931842C465F00236401D 8BD973EE
net.86400   IN  RRSIG   DS 8 1 86400 2019042505
2019
041204 25266 . Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx
eU1c
rjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt
hguq+9jcNTMAzrUXvi6Tb8oTb36
lprYIfg21yO1d8RO6cx3L0dJMcuez
WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71An
MV+nob 48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J
NkegEfRCzRZYYKiD
MwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ==
;; Received 1168 bytes from 199.9.14.201#53(b.root-servers.net) in 88 ms

comcast.net.172800  IN  NS  dns101.comcast.net.
comcast.net.172800  IN  NS  dns102.comcast.net.
comcast.net.172800  IN  NS  dns103.comcast.net.
comcast.net.172800  IN  NS  dns104.comcast.net.
comcast.net.172800  IN  NS  dns105.comcast.net.
comcast.net.86400   IN  DS  40909 5 2
30C0F50E68DCC9A2F279A9
94C07CF22CED97AADF44C2B1FE38A1B32B A1A34174
comcast.net.86400   IN  DS  40909 5 1
DDC19733884EE533B35B4B
57717BEA9B0EF2C4D1
comcast.net.86400   IN  RRSIG   DS 8 2 86400 20190417054136
2019
0410043136 51638 net.
l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f X
zNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ
yTAq2wPMGD6evSUSDLfqYu8h
oJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk=
dig: couldn't get address for 'dns101.comcast.net': no more

-Original Message-
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Friday, April 12, 2019 11:20 AM
To: Paul A 
Cc: bind-users@lists.isc.org 
Subject: Re: dns latency

Before you pay attention to the round trip time you need this fix from BIND
9.9.6 from nearly 5 years ago now (2014-07-31).

3903.  [bug]   Improve the accuracy of DiG's reported round trip
   time. [RT 36611]

Mark

> On 13 Apr 2019, at 12:59 am, Paul A  wrote:
> 
> This is not really a Bind issue, but can anyone else confirm latency 
> when querying Comcast from the root down? I ask because this morning  some
of our customers Could not email @comcast addresses, looked at the mail
server and domain not found. I suspect my cache for Comcast timeout and when
my DNS server tried doing a new query it timeout on GTLD server to Comcast?
>  
> When I query directly to their DNS servers there is no latency, so I
suspect this is a link issue at  Comcast affecting DNS?
>  
> TIA paul
>  
>  
>  
> ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @192.5.6.30 comcast.net 
> -t a +trace ; (1 server found) ;; global options: +cmd
> .   518400  IN  NS  i.root-servers.net.
> .   518400  IN  NS  j.root-servers.net.
> .   518400  IN  NS  k.root-servers.net.
> .   518400  IN  NS  l.root-servers.net.
> .   518400  IN  NS  m.root-servers.net.
> .   518400  IN  NS  a.root-servers.net.
> .   518400  IN  NS  b.root-servers.net.
> .   518400  IN  NS  c.root-servers.net.
> .   518400  IN  

dns latency

[Paul A]

This is not really a Bind issue, but can anyone else confirm latency when
querying Comcast from the root down? I ask because this morning  some of our
customers

Could not email @comcast addresses, looked at the mail server and domain not
found. I suspect my cache for Comcast timeout and when my DNS server tried
doing a new query it timeout on GTLD server to Comcast?

 

When I query directly to their DNS servers there is no latency, so I suspect
this is a link issue at  Comcast affecting DNS?

 

TIA paul  

 

 

 

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @192.5.6.30 comcast.net -t a
+trace

; (1 server found)

;; global options: +cmd

.   518400  IN  NS  i.root-servers.net.

.   518400  IN  NS  j.root-servers.net.

.   518400  IN  NS  k.root-servers.net.

.   518400  IN  NS  l.root-servers.net.

.   518400  IN  NS  m.root-servers.net.

.   518400  IN  NS  a.root-servers.net.

.   518400  IN  NS  b.root-servers.net.

.   518400  IN  NS  c.root-servers.net.

.   518400  IN  NS  d.root-servers.net.

.   518400  IN  NS  e.root-servers.net.

.   518400  IN  NS  f.root-servers.net.

.   518400  IN  NS  g.root-servers.net.

.   518400  IN  NS  h.root-servers.net.

;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms

 

net.172800  IN  NS  a.gtld-servers.net.

net.172800  IN  NS  b.gtld-servers.net.

net.172800  IN  NS  c.gtld-servers.net.

net.172800  IN  NS  d.gtld-servers.net.

net.172800  IN  NS  e.gtld-servers.net.

net.172800  IN  NS  f.gtld-servers.net.

net.172800  IN  NS  g.gtld-servers.net.

net.172800  IN  NS  h.gtld-servers.net.

net.172800  IN  NS  i.gtld-servers.net.

net.172800  IN  NS  j.gtld-servers.net.

net.172800  IN  NS  k.gtld-servers.net.

net.172800  IN  NS  l.gtld-servers.net.

net.172800  IN  NS  m.gtld-servers.net.

net.86400   IN  DS  35886 8 2
7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE

net.86400   IN  RRSIG   DS 8 1 86400 2019042505
2019041204 25266 .
Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx
eU1crjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt
hguq+9jcNTMAzrUXvi6Tb8oTb36lprYIfg21yO1d8RO6cx3L0dJMcuez
WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71AnMV+nob
48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J
NkegEfRCzRZYYKiDMwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ==

;; Received 1168 bytes from 198.97.190.53#53(h.root-servers.net) in 19 ms

 

comcast.net.172800  IN  NS  dns101.comcast.net.

comcast.net.172800  IN  NS  dns102.comcast.net.

comcast.net.172800  IN  NS  dns103.comcast.net.

comcast.net.172800  IN  NS  dns104.comcast.net.

comcast.net.172800  IN  NS  dns105.comcast.net.

comcast.net.86400   IN  DS  40909 5 2
30C0F50E68DCC9A2F279A994C07CF22CED97AADF44C2B1FE38A1B32B A1A34174

comcast.net.86400   IN  DS  40909 5 1
DDC19733884EE533B35B4B57717BEA9B0EF2C4D1

comcast.net.86400   IN  RRSIG   DS 8 2 86400 20190417054136
20190410043136 51638 net.
l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f
XzNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ
yTAq2wPMGD6evSUSDLfqYu8hoJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk=

;; Received 612 bytes from 192.42.93.30#53(g.gtld-servers.net) in 25090 ms

 

comcast.net.30  IN  A   69.252.80.75

comcast.net.30  IN  RRSIG   A 5 2 30 20190418174157
20190411143657 26550 comcast.net.
YegwZlzjBoJ+b9nWTHwRZQbce619UcOVdo6FUPG056Sod4MEchv/GCHu
7BpREAUm0CBoE4qbipTiS47wIk7QJYzz10B78wRgMGNwMTUXQ571YRyq
P0I3I0Dzag28j607walJOZms3lAXDzSnyvv9wocaH2MJ7Z3j68Qf5pKh YpM=

;; Received 227 bytes from 69.252.250.103#53(dns101.comcast.net) in 14 ms

 

___
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

Re: Help: BIND _ Recursive query

[Paul Kosinski]

I gather "recursion yes" (explicit or default) controls whether BIND
*does* recursion itself, in the sense of querying other DNS servers for
data it doesn't have, not whether it *issues* queries with the
"recursion desired" flag set. (Somewhat confusing terminology, in my
opinion.)

So is the "recursion desired" flag only set when there are forwarders?
Presumably it is set in the case of "forward only", but what happens if
there are forwarders defined and both "recursion yes" (default) and
"forward first" (default) are specified?


On Mon, 4 Mar 2019 19:30:36 +0100
Matus UHLAR - fantomas  wrote:

> >On 4 Mar 2019, at 16:20, Paul Kosinski wrote:
> >> provides our users with general caching DNS service for
> >> all other domains.
> >
> >[...]
> >
> >> Its "named.conf" file doesn't list any "forwarders" any more, and
> >> "forward-only" is gone, but it still has a leftover "recursion yes"
> >> clause. Am I correct is assuming that this is now useless and can
> >> be removed?
> 
> On 04.03.19 16:33, Niall O'Reilly wrote:
> >If you want "general caching DNS service" to continue to work,
> >you'll need to keep "recursion yes".
> 
> actually "recursion yes;" is the default, so if you remove it, it
> stays set to yes (unless it's set to "no" somewhere).
> 
> recursion is the feature that allows BIND to resolve domains not
> configured locally, you surely need it enabled.
___
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

Re: Problems removing a domain

[Paul van der Vlis]

Op 05-03-19 om 16:32 schreef Matus UHLAR - fantomas:
>>> On 05.03.19 14:41, Paul van der Vlis wrote:
>>>> This was a long time ago. In the meantime I have rebooted the server.
>>>>
>>>> What I see, is that the resolving does not work from other locations.
>>>>
>>>> Only when I use my own nameserver the domain is resolved, and it gives
>>>> an "Non-authoritative answer".
>>>
>>> both kinds of behaviour indicate that the domain is not configured on
>>> your
>>> BIND server, but it was resolved using recursion
>>>
>>>> Any idea how to delete this?
>>>
>>> delete what? the domain does not exist now, but it's configured and
>>> delegated. your BIND may have cached local copy, or you have
>>> forwarding set> to a server which does know the domain.
>>
>> No, I have never done that.
>>
>>> can you use "dig" instead of "host" to see what does your BIND know?
>>>
>>> dig any extensus.nl.
> 
> On 05.03.19 16:20, Paul van der Vlis wrote:
>> root@ns1:/etc/bind/domeinen# dig any @localhost extensus.nl
>>
>> ; <<>> DiG 9.10.3-P4-Debian <<>> any @localhost extensus.nl
>> ; (2 servers found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57790
>    
> SERVFAIL here.
> 
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;extensus.nl.    IN    ANY
>>
>> ;; Query time: 53 msec
>> ;; SERVER: ::1#53(::1)
>> ;; WHEN: Tue Mar 05 16:12:54 CET 2019
>> ;; MSG SIZE  rcvd: 40
>>
>> root@ns1:/etc/bind/domeinen#
>> -
> 
> this is the proper and expected response, since the extensus.nl domain is
> delegated to servers that don't know about it.
>> But... I think I found it:
>> --
>> root@ns1:/etc/bind/domeinen# rndc flushtree extensus.nl
>> root@ns1:/usr/local/sbin# nslookup extensus.nl localhost
>> ;; Got SERVFAIL reply from ::1, trying next server
>> Server:    localhost
>> Address:    127.0.0.1#53
>>
>> ** server can't find extensus.nl: SERVFAIL
>>
>> root@ns1:/usr/local/sbin#
>> --
> 
> this is in fact the same result, using the obsolete "nslookup" command
> see the SERVFAIL in dig output above.

Dig does something else then nslookup.
Nslookup gave response before the "rndc flushtree", dig did not.

With regards,
Paul van der Vlis



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

___
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

Re: Problems removing a domain

[Paul van der Vlis]

Op 05-03-19 om 15:21 schreef Matus UHLAR - fantomas:
>>> On 05/03/2019 01:01, Paul van der Vlis wrote:
>>>> Not sure. It was a domain used for testing purposes.
>>>>
>>>> Before it was in /etc/bind/named.conf.local, but I removed it from
>>>> there.
> 
>> Op 05-03-19 om 11:51 schreef Anand Buddhdev:
>>> Did you run "rndc reconfig" after removing it from the named.conf.local
>>> file?
> 
> On 05.03.19 14:41, Paul van der Vlis wrote:
>> This was a long time ago. In the meantime I have rebooted the server.
>>
>> What I see, is that the resolving does not work from other locations.
>>
>> Only when I use my own nameserver the domain is resolved, and it gives
>> an "Non-authoritative answer".
> 
> both kinds of behaviour indicate that the domain is not configured on your
> BIND server, but it was resolved using recursion
> 
>> Any idea how to delete this?
> 
> delete what? the domain does not exist now, but it's configured and
> delegated. your BIND may have cached local copy, or you have forwarding set> 
> to a server which does know the domain.

No, I have never done that.

> can you use "dig" instead of "host" to see what does your BIND know?
> 
> dig any extensus.nl.

-
root@ns1:/etc/bind/domeinen# dig any @localhost extensus.nl

; <<>> DiG 9.10.3-P4-Debian <<>> any @localhost extensus.nl
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57790
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;extensus.nl.   IN  ANY

;; Query time: 53 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Mar 05 16:12:54 CET 2019
;; MSG SIZE  rcvd: 40

root@ns1:/etc/bind/domeinen#
-

But... I think I found it:
--
root@ns1:/etc/bind/domeinen# rndc flushtree extensus.nl
root@ns1:/usr/local/sbin# nslookup extensus.nl localhost
;; Got SERVFAIL reply from ::1, trying next server
Server: localhost
Address:127.0.0.1#53

** server can't find extensus.nl: SERVFAIL

root@ns1:/usr/local/sbin#
--

With regards,
Paul van der Vlis.


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

___
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

Re: Problems removing a domain

[Paul van der Vlis]

Op 05-03-19 om 11:51 schreef Anand Buddhdev:
> On 05/03/2019 01:01, Paul van der Vlis wrote:
> 
>> Not sure. It was a domain used for testing purposes.
>>
>> Before it was in /etc/bind/named.conf.local, but I removed it from there.
> 
> Did you run "rndc reconfig" after removing it from the named.conf.local
> file?

This was a long time ago. In the meantime I have rebooted the server.

What I see, is that the resolving does not work from other locations.

Only when I use my own nameserver the domain is resolved, and it gives
an "Non-authoritative answer".

Any idea how to delete this?

With regards,
Paul van der Vlis



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
___
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

Re: Problems removing a domain

[Paul van der Vlis]

Op 05-03-19 om 00:56 schreef Jie Gao:
> # man rndc
> ...
> delzone [-clean] zone [class [view]]
>Delete a zone while the server is running. Only zones that were 
> originally added via rndc addzone can be deleted in this manner.
> 
> ...
> 
> 
> Was this zone added via "rndc addzone" originally?

Not sure. It was a domain used for testing purposes.

Before it was in /etc/bind/named.conf.local, but I removed it from there.

With regards,
Paul van der Vlis




> Regards,
> 
> 
> Jie
> 
> * Paul van der Vlis  wrote:
> 
>> Date: Tue, 5 Mar 2019 00:47:55 +0100
>> From: Paul van der Vlis 
>> To: bind-us...@isc.org
>> Subject: Problems removing a domain
>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
>>  Thunderbird/60.5.1
>>
>> Hello,
>>
>> I have problems removing a domain from an authoritative nameserver:
>> ---
>> root@ns1:/var/cache/bind# rndc delzone extensus.nl
>> rndc: 'delzone' failed: not found
>> no matching zone 'extensus.nl' in any view
>> root@ns1:/var/cache/bind# host extensus.nl localhost
>> Using domain server:
>> Name: localhost
>> Address: ::1#53
>> Aliases:
>>
>> extensus.nl has address 91.198.178.59
>> extensus.nl has IPv6 address 2a01:1b0:7999:424::59
>> extensus.nl mail is handled by 20 mail2.vandervlis.nl.
>> extensus.nl mail is handled by 10 mail.vandervlis.nl.
>> root@ns1:/var/cache/bind# rgrep extensus.nl /etc/bind
>> root@ns1:/var/cache/bind# rgrep extensus.nl /var/cache/bind
>> Binary file /var/cache/bind/_default.nzd matches
>> 
>>
>> I've also tried to add and remove it again, but I don't get it away.
>>
>> Somebody an idea?
>>
>> With regards,
>> Paul van der Vlis
>>
>>
>> -- 
>> Paul van der Vlis Linux systeembeheer Groningen
>> https://protect-au.mimecast.com/s/SUlGC81Zj6tmP2gvFnMl7U?domain=vandervlis.nl
>>
>> ___
>> Please visit 
>> https://protect-au.mimecast.com/s/FkoyC91ZkQtJNlj3UEUDhF?domain=lists.isc.org
>>  to unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://protect-au.mimecast.com/s/FkoyC91ZkQtJNlj3UEUDhF?domain=lists.isc.org
>>



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
___
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

Problems removing a domain

[Paul van der Vlis]

Hello,

I have problems removing a domain from an authoritative nameserver:
---
root@ns1:/var/cache/bind# rndc delzone extensus.nl
rndc: 'delzone' failed: not found
no matching zone 'extensus.nl' in any view
root@ns1:/var/cache/bind# host extensus.nl localhost
Using domain server:
Name: localhost
Address: ::1#53
Aliases:

extensus.nl has address 91.198.178.59
extensus.nl has IPv6 address 2a01:1b0:7999:424::59
extensus.nl mail is handled by 20 mail2.vandervlis.nl.
extensus.nl mail is handled by 10 mail.vandervlis.nl.
root@ns1:/var/cache/bind# rgrep extensus.nl /etc/bind
root@ns1:/var/cache/bind# rgrep extensus.nl /var/cache/bind
Binary file /var/cache/bind/_default.nzd matches


I've also tried to add and remove it again, but I don't get it away.

Somebody an idea?

With regards,
Paul van der Vlis


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

___
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

Re: Help: BIND _ Recursive query

[Paul Kosinski]

We have a BIND server on our LAN which is authoritative for our ".local"
domain and also provides our users with general caching DNS service for
all other domains.

Its "named.conf" file doesn't list any "forwarders" any more, and
"forward-only" is gone, but it still has a leftover "recursion yes"
clause. Am I correct is assuming that this is now useless and can be
removed?

Thanks.


On Mon, 4 Mar 2019 07:37:11 +1100
Mark Andrews  wrote:

> Iterative mode is the default lookup mode for recursive servers.  It
> is where the server follows the delegations from the root servers to
> talk to the authoritative servers directly.  Recursive mode is where
> you use another recursive server (in iterative mode) to talk to the
> authoritative servers. Stub resolvers (in applications) use recursive
> mode.
> 
> > On 4 Mar 2019, at 2:17 am, Matus UHLAR - fantomas
> >  wrote:
> > 
> > On 03.03.19 07:36, vivek wrote:
> >> thanks, that means for Bind service to work  we have to have the
> >> "recursion yes" else the forwarder will also not work.
> >> 
> >> Actually I m bit confused between Recursive vs Iterative query
> >> mode , so does this mean Bind will only work in Recursive query
> >> mode & this makes the "Forwarder "  to do his required job.
> >> 
> >> Help in understand so in what scenarios will use/configure Bind in
> >> Iterative query mode.
> > 
> > iterative mode happend when domain is configured locally, otherwise
> > recursive mode is used. you don't need to configure it.
___
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

Re: Forward zone inside a view

[Paul Kosinski]

I haven't analyzed the details and pitfalls, but could a Web proxy
mechanism of some sort be of help? In particular, rather than having
your users directly access "teamviewer.org" (or whatever), have them to
access "teamviewer.local", which is resolved by your internal DNS to a
specialized proxy server.

Then set up this proxy server to forward those requests to
"teamviewer.org", *not* its IP address (since that can, of course,
change). This is likely the hard part, but the proxy can at least
assume that it never gets HTTP(S) requests in general. 

In other words, move the mapping one level up in the protocol stack,
from the DNS layer to the HTTP(S) layer.

And, if the proxy can support the equivalent of name-based hosting, then
it could support multiple local domain redirects, if needed in the
future. 

P.S. PRIVOXY is probably able at least to do the redirect for a single
domain -- and it's lightweight.




On Thu, 7 Feb 2019 15:00:47 -0500
Alan Clegg  wrote:

> On 2/7/19 2:30 PM, Roberto Carna wrote:
> > Dear, thanks for your contact. I've used teamviewer.com
> >  just for tests.
> > 
> > Desktops I mentioned can only access to web apps from internal
> > domains, but in some web apps there are links to download
> > Teamviewer client software from Internet. I can create a private
> > zone "teamviewer.com " with all the
> > hostnames and IP's we will use, but if they change I will be in
> > trouble.
> 
> Sounds to me like a use for a global block with RPZ and a passthrough
> for the domain that needs to be ... uh ... passed through.
> 
> And from my experience, this is never going to work because whatever
> the "only thing we want to resolve" is, it will rely on something
> else that you don't (currently) resolve.
> 
> Anyone that has ever tried to block their "smart TV" so that it only
> allows certain apps but not others will know exactly what I'm talking
> about.
> 
> AlanC

___
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

error sending response: would block

[Paul B. Henson]

I recently updated a couple servers that were running OpenBSD 6.3 with
bind 9.11.3 to OpenBSD 6.4 and bind 9.11.4pl2. Since then, I'm been
getting a large number of "error sending response: would block" log
messages:

Nov 15 11:03:58 lisa named[79587]: client @0x6f2f02bc440
10.128.30.77#65198 (p64-keyvalueservice.icloud.com): view internal:
error sending response: would block
Nov 15 11:07:42 lisa named[79587]: client @0x6f325b7a440
10.128.0.19#1851 (alt1.gmail-smtp-in.l.google.com): view internal: error
sending response: would block

I reviewed the article at https://kb.isc.org/docs/aa-00717 ; but it's
not clear - is this just a warning message, and it tries again and
successfully responds to the client, or is this a hard error and the
client never gets a response?

I wasn't getting any errors before the upgrade, and I don't think the
load on these servers is anywhere near high enough to cause them to be
overloaded.

Any thoughts on what might be going on?

Thanks...

___
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

Re: Question about visibility

[Paul Kosinski]

Maybe port scanners will find open ports pretty quickly, but I've found
that using non-standard ports is helpful in reducing traffic, at least.
For example, SSH on port 22 gets lots of SYNs but moving it elsewhere,
and making 22 totally unresponsive discourages most such attempts. This
increases security slightly a priori, and may also improve security by
simplifying the firewall log(s).

When using OpenVPN over UDP, the standard port 1194 can be subject to
random and/or attack packets. These have to be processed and rejected
(since their HMACs etc. hopefully won't pass decryption). This won't
occur in TCP mode, of course, but UDP tends to be more efficient,
especially since TCP over TCP tends to clog up.

P.S. When you come right down to it, *all* computer (software) security
is "security by obscurity", whether the obscurity of passwords, private
keys, etc. For example, DES is no longer used because 56-bit keys are no
longer obscure enough to hide from modern computers.


On Wed, 24 Oct 2018 13:24:41 +
Timothy Metzinger  wrote:

> There's no security in obscurity.  Automated port scanners will sweep
> your system in a couple of seconds.
> 
> Tim Metzinger
> 
> From: bind-users  on behalf of G.W.
> Haywood via bind-users  Sent: Wednesday,
> October 24, 2018 12:15:10 PM To: bind-users@lists.isc.org
> Subject: Re: Question about visibility
> 
> Hi there,
> 
> On Wed, 24 Oct 2018, Hardy, Andrew wrote:
> 
> > Further to the original post, as well as not creating a DNS record
> > and "possibly" adding robot.txt with appropriate content, as
> > discussed, I presume that if I run the http server on a personally
> > selected unprivileged port then it is very "unlikely" the site pages
> > will be indexed/discovered/etc surely?
> >
> > Thoughts?
> 
> A server on a non-standard port is often neglected.  Its security may
> be less well maintained than one that is intentionally public.
> 
> That's just the sort of thing that criminals are looking for.  They'll
> probably find it, and then they'll attack it.
> 
> --
> 
> 73,
> Ged.
> ___
> Please visit
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=02%7C01%7C%7C0b805cc1bd334bd7ea4808d639aa77ec%7C84df9e7fe9f640afb435%7C1%7C0%7C636759801644561901sdata=CqjF4k0IMJVEbFnKVPzflLNxc8LyguCF7iSblAfVbLI%3Dreserved=0
> to unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=02%7C01%7C%7C0b805cc1bd334bd7ea4808d639aa77ec%7C84df9e7fe9f640afb435%7C1%7C0%7C636759801644561901sdata=CqjF4k0IMJVEbFnKVPzflLNxc8LyguCF7iSblAfVbLI%3Dreserved=0
> 
> Tim Metzinger
> 703.963.3015
> 
___
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

Re: Operational Notification: Some releases of BIND are too strict when handling referrals containing non-empty answer sections

[Paul Kosinski]

Code refactoring is nothing compared to what Mozilla did to Firefox!

It's hard to believe they didn't change the name, given that they
totally changed the add-on interface and thereby removed so many of the
features that made Firefox our browser of choice.


On Thu, 20 Sep 2018 09:48:08 +0100 (BST)
"G.W. Haywood via bind-users"  wrote:

> Hi there,
> 
> On Wed, 19 Sep 2018, Michael McNally wrote:
> 
> >   ... code refactoring ...
> 
> That phrase always sends shudders through my corpus.
> 
___
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

Re: Sign ZSK key permanently

[Paul van der Vlis]

Hi Tony,

Thanks for your answer!

Op 23-08-18 om 18:40 schreef Tony Finch:
> Paul van der Vlis  wrote:
>>
>> Is it possible to sign the ZSK key permanently with the KSK key?
>> In this way I could keep the KSK key offline.
> 
> The only(*) revocation mechanisms in DNSSEC are expiring signatures and
> replacing keys. If you sign your DNSKEY records permanently, when anyone
> manages to compromise them they will be able to spoof records in your zone
> until you replace the KSK.
> 
> In effect, what you will have done is coupled the keys together
> permanently so they are of equivalent power, and eliminated all benefit of
> keeping the KSK offline.
>
> The point of an offline KSK is to allow you to recover from compromise of
> your ZSK without having to replace your DS records or other trust anchors.

If the ZSK and KSK are on the same place, they will be compromized
together I would say.

> It's worth having a look at how the root DNSKEY RRset is managed: they get
> the KSK out of storage a few times a year, when they generate RRSIG
> records for the next few months.

A long TTL is needed then.

> (*) The other mechanism is the RFC 5011 revoked bit, which only applies to
> KSKs that are being tracked as auto-updating trust anchors (managed-keys
> etc.) but that doesn't apply to other records that depend on signature and
> key rotation for revocation.
Isn't it possible to revoke the ZSK key, and sign the zone with a new
ZSK key?

Without an offline KSK, I do not see a reason for both a KSK and a ZSK
key. Do you?

With regards,
Paul van der Vlis

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
___
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

Sign ZSK key permanently

[Paul van der Vlis]

Hello,

Is it possible to sign the ZSK key permanently with the KSK key?
If yes:  how to do that?

In this way I could keep the KSK key offline.

With regards,
Paul van der Vlis


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

___
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

Re: SRV record not working

[Paul Kosinski]

Extra complexity -- "man dig" yields 289 lines while "man nslookup"
yields only 160 lines.

Also, dig is not simply an extension of nslookup (which I long ago
abbreviated to nsl), but is significantly different, so it using it
involves the human analog of a cache miss.


On Sat, 18 Aug 2018 20:12:01 +0200
Reindl Harald  wrote:

> 
> 
> Am 18.08.2018 um 20:02 schrieb Paul Kosinski:
> > When I started using Linux almost 20 years ago, I think there was
> > only nslookup, and no dig. So by habit, I tend to use it unless the
> > extra power of dig outweighs its extra complexity. 
> 
> which extra complexity?
> 
> because you have to add an @ when you want to use a non-default
> nameserver and that you need "dig -X" for a reverse-lookup?
> 
> you can use dig as nslookup, it's not required that you add a record
> type - just "dig whatever" which is in that case even shorter
> 
> > On Sat, 18 Aug 2018 11:42:20 -0600
> > Grant Taylor via bind-users  wrote:
> > 
> >> On 08/18/2018 07:25 AM, Bob McDonald wrote:
> >>> I don't think anyone hates nslookup (well maybe a few do )
> >>> I suppose the immense dislike stems from the fact that it's the
> >>> default utility under Windows. Folks who use dig as their default
> >>> realize that when used properly, dig provides much more
> >>> functionality than nslookup. For example, try using TSIG with
> >>> nslookup or getting a NSID response. These are only a couple of
> >>> examples. There's other reasons to change. The output from dig is
> >>> much more comprehensive. And, yes, if you install the bind tools
> >>> from ISC under Windows, dig works quite well.
> >>
> >> I've been told that nslookup will lie and provide incorrect
> >> information in some situations.  I have no idea what situations
> >> that is.  I would love to learn what they are.
> >>
> >> If you know of such an example, please enlighten me.
> >>
> >> As such, I tend to use nslookup on platforms without dig when or
> >> until I have reason to not do so
> 
> 
___
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

Re: SRV record not working

[Paul Kosinski]

When I started using Linux almost 20 years ago, I think there was only
nslookup, and no dig. So by habit, I tend to use it unless the extra
power of dig outweighs its extra complexity. I don't remember what I
used on Windows back when I was regularly using both.


On Sat, 18 Aug 2018 11:42:20 -0600
Grant Taylor via bind-users  wrote:

> On 08/18/2018 07:25 AM, Bob McDonald wrote:
> > I don't think anyone hates nslookup (well maybe a few do ) I 
> > suppose the immense dislike stems from the fact that it's the
> > default utility under Windows. Folks who use dig as their default
> > realize that when used properly, dig provides much more
> > functionality than nslookup. For example, try using TSIG with
> > nslookup or getting a NSID response. These are only a couple of
> > examples. There's other reasons to change. The output from dig is
> > much more comprehensive. And, yes, if you install the bind tools
> > from ISC under Windows, dig works quite well.
> 
> I've been told that nslookup will lie and provide incorrect
> information in some situations.  I have no idea what situations that
> is.  I would love to learn what they are.
> 
> If you know of such an example, please enlighten me.
> 
> As such, I tend to use nslookup on platforms without dig when or
> until I have reason to not do so.
> 
> 
> 
___
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

DMARC question

[Paul Kosinski]

We have a couple of small domains whose DNS is served by BIND on our dedicated 
machines. Almost 3 years ago we had set up DMARC records, and were getting 
reports from various MXs every day until a couple of days ago (Aug 13). Then 
they suddenly stopped!

Nothing in the BIND config or zone files was changed, and our Postfix mail logs 
(on our dedicated server) don't show *anything* addressed to our DMARC target 
since then. (I.e., it's not that our spam filtering is dropping them.)

Has anyone ever observed anything like this?

Thanks!
___
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

Re: Domain name based multihome routing?

[Paul Kosinski]

We do something somewhat similar with our LAN. We have a new cable
connection and an old DSL connection. The cable is 60x faster, but has
a dynamic IP and blocks various ports (esp. 25), so we keep the DSL so
we can send email directly etc.

Obviously, we don't want to stream video or even do much Web browsing
over the DSL. So we have set up a Linux computer to serve as a gateway
and firewall: it runs IPtables, Privoxy, HAVP (virus filter for HTTP),
ClamAV and even Bind (a 3rd DNS server for our small domains).

This works fairly straightforwardly because decision as to whether to
use cable or DSL is made according to the *source* IP address, rather
than the destination IP address (or domain name, or port). Since
many browsers (we use Firefox) and other Internet software have the
ability to specify a proxy for Internet access, we usually connect them
to a proxy server on the gateway which in turn binds to an alias IP on
either the NIC connected to the DSL modem or the cable modem.

Then we have 2 routing tables, the default one for the (original) DSL
and a second one for cable. Each routing table gas its own default
route, and each is 'via' the corresponding modem.  To decide which way
packets go, we make use of a 'rule' table (iproute2) which says which
routing table to use. It has entries generated by iproute2 functions
such as:

  /sbin/ip rule add from lookup cable
  /sbin/ip rule add to lookup cable
  /sbin/ip rule add iif  br2   lookup cable

This last rule says the *everything* from (sub) LAN 2 goes via cable.
This allows whole sets of devices (such as our computer dedicated to TV)
to be connected strictly to cable.

Note that even though you bind to an alias IP on the NIC physically
connected to a specific modem, if that modem isn't the overall default
route, you still need a 'rule' to make the kernel do the right thing.

In summary, this scheme does not give you totally automatic control of
what kind of traffic goes by what physical link, but it does allow
different browser instances on a single computer to use different
physical links via proxying, plus it easily allows different devices on
the LAN to be handled differently (since they each have their own IP
address).

--

On Wed, 27 Jun 2018 13:17:41 -0500
Dale Mahalko  wrote:

> On Wed, Jun 27, 2018 at 12:27 PM, Darcy Kevin (FCA) <
> kevin.da...@fcagroup.com> wrote:
> 
> > I’m not convinced DNS has any valuable role to play here. Seems
> > like this is a traffic-shaping challenge; maybe one of the open
> > source traffic shaping tools would fit the bill.
> >
> 
> A Google search for multihome traffic shaping yields nothing obvious.
> 
> Do you have specific details you can share about exactly how that
> would be done?
> 
> Also how is traffic shaping going to tell the difference between a
> background Apple iOS update or Windows update that need to use the
> DSL, and the high priority data streams that are more important to
> me, that need to use the cellular modem?
> 
> 
> Shaping is not routing, it just prioritizes some data streams over
> others. I don't see how shaping is going to know whether to use the
> DSL or the Cellular ... without inspecting the domain name before a
> connection is established which is what I'm already discussing
> here...
___
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

Re: Stopping name server abuse

[Paul Kosinski]

Most of your replies seem not to address the (immediately
preceding) paragraph they appear to be responding to.


On Mon, 25 Jun 2018 22:15:07 +0200
Reindl Harald  wrote:

> 
> 
> Am 25.06.2018 um 22:01 schrieb Paul Kosinski:
> > Somebody who has irresponsibly (and apparently wantonly, given his
> > refusal to fix it) delegated his domain(s) to your DNS server is
> > essentially causing a (modest bandwidth) distributed denial of
> > service attack on your server. I don't think that the "responsible"
> > thing to do is to sit there and suffer from a significantly
> > increased load.
> 
> no, but you proposed timeout don't change that anyways
> it makes things only worser
> 
> if you have noticeable increased load in real life becuase of some
> domains you no longer want to host on a nameserver you are lost
> anyways and calling that a distributed denial of service is a joke
> 
> > What should be done is to get the domain(s) revoked if the owner
> > continues to refuse to remedy the problem: it is *he*, not you, who
> > is being irresponsible. 
> 
> if you make things worser for everyone without any gain *you are*
> irresponsible because you don't understand the outcome of your actions
> like funny timeouts
> 
> > And if the queries are coming via an innocent
> > ISP's resolver, then they are inadvertently assisting in the attack,
> > and should be contacted and asked to help in the remediation. (Note
> > that *their* resources, as well as yours, are being wasted.)
> 
> you will contact every ISP and resolver admin out there?
> seriously?
> and ask them to do what exactly?
> 
> if you call me and tell me your story about domains pointing to your
> nameserver and why we as ISP don#t stop asking the response you
> deserve is not allowed legally
> 
> the question was how to reduce the load and your answers where how to
> increase load and make things worser for everybody and things much
> complexer - the only correct way to get this *finally* resolved is
> force the registry of the domain to remove your nameservers and
> that's it instead of calling innocent parties or playing technical
> games with no gain
___
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

Re: Stopping name server abuse

[Paul Kosinski]

Somebody who has irresponsibly (and apparently wantonly, given his
refusal to fix it) delegated his domain(s) to your DNS server is
essentially causing a (modest bandwidth) distributed denial of service
attack on your server. I don't think that the "responsible" thing to do
is to sit there and suffer from a significantly increased load.

What should be done is to get the domain(s) revoked if the owner
continues to refuse to remedy the problem: it is *he*, not you, who is
being irresponsible. And if the queries are coming via an innocent
ISP's resolver, then they are inadvertently assisting in the attack,
and should be contacted and asked to help in the remediation. (Note
that *their* resources, as well as yours, are being wasted.)


On Mon, 25 Jun 2018 17:47:23 +0200
Reindl Harald  wrote:

> Am 25.06.2018 um 17:37 schrieb Barry Margolin:
> > In article ,
> >  Paul Kosinski  wrote:
> > 
> >> How does *not* responding to a UDP query take longer for the
> >> *server* than responding to UDP a query? Both responding and
> >> (deliberately) not responding require identifying the query, but
> >> not responding bypasses the time the server would need to
> >> construct the response, plus time spent in the network stack. (I'm
> >> assuming we don't care about client side "expense".)
> > 
> > If there's no response, the client retries several times. It will
> > try all the servers that the zone is delegated to, so you'll put
> > more load on multiple servers.
> > 
> > NXDOMAIN responses are cached, it's one hit and then nothing for a
> > while
> 
> and additionally "I'm assuming we don't care about client side
> "expense" is nonsense because the client in question is typically a
> *innocent* ISP resolver or something like 8.8.8.8 and the attitude "i
> don't care about them" is irresponsible because as sysadmin you are
> expected to think what your actions mean for the whole ecosystem
> 
> 
___
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

Re: Stopping name server abuse

[Paul Kosinski]

How does *not* responding to a UDP query take longer for the *server*
than responding to UDP a query? Both responding and (deliberately) not
responding require identifying the query, but not responding bypasses
the time the server would need to construct the response, plus time
spent in the network stack. (I'm assuming we don't care about client
side "expense".)

Of course, if not responding to a UDP query provokes a TCP query, that
might increase the total server time needed, since TCP is inherently
more expensive for short transactions like DNS.

P.S. If you have something like iptables (with its string matching) in
front of your DNS server, you could just drop UDP queries for bogus
domains rather than letting them in at all. Or you could even route
them to a special lightweight server that just yields canned responses.
(This wouldn't work for TCP, because the query doesn't come until after
the connection is established.)



On Mon, 25 Jun 2018 15:32:44 +0200
Reindl Harald  wrote:

> 
> 
> Am 25.06.2018 um 05:39 schrieb Paul Kosinski:
> > Is it possible to get BIND not to respond at all, thereby causing
> > a timeout on the query? That would perhaps reduce load more than
> > NXDOMAIN or deleting the sone(s) would.
> 
> timeouts are expensive for both sides by definition
> 
> > On Mon, 25 Jun 2018 00:03:09 +0200
> > jo...@hasig.de wrote:
> > 
> >> yes, but it minimizes the use of resources because the only answer
> >> is nxdomain. j.
> >>
> >> Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> >>> In article ,
> >>>   jo...@hasig.de wrote:
> >>>
> >>>> hi,
> >>>> why dont you just delete the zones?
> >>>
> >>> That won't stop the queries from coming to the server
> 
> 
___
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

Re: Stopping name server abuse

[Paul Kosinski]

Is it possible to get BIND not to respond at all, thereby causing
a timeout on the query? That would perhaps reduce load more than
NXDOMAIN or deleting the sone(s) would.


On Mon, 25 Jun 2018 00:03:09 +0200
jo...@hasig.de wrote:

> yes, but it minimizes the use of resources because the only answer is
> nxdomain. j.
> 
> Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> > In article ,
> >   jo...@hasig.de wrote:
> > 
> >> hi,
> >> why dont you just delete the zones?
> > 
> > That won't stop the queries from coming to the server.
___
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

Re: BIND srtt algorithm not working as expected

[Paul Roberts]

Hey Nico, long time no speak, hope you are well! You still at Efficient IP?


Yes that would be a great idea in theory but in practice it would require a 
massive infrastructure change for this customer, we'd also have to migrate the 
anycast IPs to these new nodes (does dnsdist support anycast?), and ensure we 
can still meet the contracted SLAs. Basically it's a lot of work (+ cost) just 
to "sort out" this Sophos mess.


I'd rather Sophos did their stuff over a separate TCP or UDP port rather than 
hijacking DNS, but doubt they will listen to "little old me". 


Cheers,


Paul




From: Nico CARTRON <nico...@ncartron.org>
Sent: 17 May 2018 13:01
To: Paul Roberts
Cc: ML BIND Users
Subject: Re: BIND srtt algorithm not working as expected

Hi Paul,

On 17 May 2018, at 13:46, Paul Roberts 
<p...@callevanetworks.com<mailto:p...@callevanetworks.com>> wrote:

Good grief indeed!

I would love to implement 'fetches-per-zone' but we need to get them onto BIND 
9.11 first, that's a few months away.

Unfortunately I can't just block this traffic else I'll have the security teams 
wanting to know why we are compromising their desktop security.

Even 'fetches-per-zone' is a bit contentious, if we are rate limiting and one 
of those queries happens to be for a malicious file which doesn't get 
quarantined (because we never got the actionable response code from Sophos) 
we'll be in big trouble.

So we are caught between a rock and a hard place. :-(

Why not putting dnsdist in front of those BIND 9.8, and having it redirect DNS 
traffic at destination of Sophos to dedicated BIND servers?
And have the other, non Sophos DNS traffic, sent to the current BIND servers?

Cheers,
Nico



From: Tony Finch <d...@dotat.at<mailto:d...@dotat.at>>
Sent: 17 May 2018 12:34
To: Paul Roberts
Cc: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Re: BIND srtt algorithm not working as expected

Paul Roberts <p...@callevanetworks.com<mailto:p...@callevanetworks.com>> wrote:

> After doing some more packet captures, it looks like a lot of the
> queries are related to Sophos live protection DNS lookups (lots of
> queries for sophosxl.net<http://sophosxl.net>), so there are a lot of queries 
> which don't get
> resolved.

Good grief.

There are a few things you might do to mitigate this idiocy:

0. Block sophosxl.net<http://sophosxl.net>. Your colleagues responsible for AV 
might not
   appreciate this :-)

1. In BIND 9.11+ there are options `fetches-per-zone` and
   `fetches-per-server` for helping a resolver to cope with overloaded
   authoritative servers. When you are forwarding you'll have to rely on
   fetches-per-zone since fetches-per-server will throttle everything.
   I don't know how fetches-per-zone discovers zone cuts or how well that
   works in the forwarding case when your resolver is relying on an
   upstream to do the iteration.

2. Set up sacrificial forwarding IP addresses. These can be additional
   addresses on your existing forwarders. Configure your resolvers to
   forward queries for sophosxl.net<http://sophosxl.net> to the sacrificial 
addresses instead
   of the usual ones. Then BIND's address database entries used by most
   queries won't get polluted by the non-responding servers.

You might profitably combine 1. and 2. to make the resolver eagerly drop
queries to the sacrificial forwarders.

Tony.
--
f.anthony.n.finch  <d...@dotat.at<mailto:d...@dotat.at>>  http://dotat.at/

the quest for freedom and justice can never end
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users

___
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

Re: BIND srtt algorithm not working as expected

[Paul Roberts]

Good grief indeed!


I would love to implement 'fetches-per-zone' but we need to get them onto BIND 
9.11 first, that's a few months away.


Unfortunately I can't just block this traffic else I'll have the security teams 
wanting to know why we are compromising their desktop security.

Even 'fetches-per-zone' is a bit contentious, if we are rate limiting and one 
of those queries happens to be for a malicious file which doesn't get 
quarantined (because we never got the actionable response code from Sophos) 
we'll be in big trouble.

So we are caught between a rock and a hard place. :-(


From: Tony Finch <d...@dotat.at>
Sent: 17 May 2018 12:34
To: Paul Roberts
Cc: bind-users@lists.isc.org
Subject: Re: BIND srtt algorithm not working as expected

Paul Roberts <p...@callevanetworks.com> wrote:

> After doing some more packet captures, it looks like a lot of the
> queries are related to Sophos live protection DNS lookups (lots of
> queries for sophosxl.net), so there are a lot of queries which don't get
> resolved.

Good grief.

There are a few things you might do to mitigate this idiocy:

0. Block sophosxl.net. Your colleagues responsible for AV might not
   appreciate this :-)

1. In BIND 9.11+ there are options `fetches-per-zone` and
   `fetches-per-server` for helping a resolver to cope with overloaded
   authoritative servers. When you are forwarding you'll have to rely on
   fetches-per-zone since fetches-per-server will throttle everything.
   I don't know how fetches-per-zone discovers zone cuts or how well that
   works in the forwarding case when your resolver is relying on an
   upstream to do the iteration.

2. Set up sacrificial forwarding IP addresses. These can be additional
   addresses on your existing forwarders. Configure your resolvers to
   forward queries for sophosxl.net to the sacrificial addresses instead
   of the usual ones. Then BIND's address database entries used by most
   queries won't get polluted by the non-responding servers.

You might profitably combine 1. and 2. to make the resolver eagerly drop
queries to the sacrificial forwarders.

Tony.
--
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/

the quest for freedom and justice can never end
___
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

Re: BIND srtt algorithm not working as expected

[Paul Roberts]

After doing some more packet captures, it looks like a lot of the queries are 
related to Sophos live protection DNS lookups (lots of queries for 
sophosxl.net), so there are a lot of queries which don't get resolved. We see 
multiple queries for the same name and the resolver seems to retransmit to each 
forwarder when it doesn't get a response, including the non-local ones. So the 
behaviour may be being exacerbated by these non-resolvable queries. Eventually 
after about 10 seconds, the forwarder replies with a SERVFAIL response as it 
eventually gives up trying to get a response from the Sophos name servers.


So now I am not sure if the rtt algorithm is completely at fault here as BIND 
is simply trying additional forwarders in an attempt to resolve the name.


I have seen this live protection stuff going on in quite a few corporates now, 
and each time we have had to raise the recursive-client limit. I don't think 
it's just Sophos that do this, pretty sure I saw this  with McAfee a couple 
years ago too, they seem to use DNS to transmit file name hashes so they can do 
a reputation lookup, but for Sophos they only reply if some kind of action is 
required. There must be many corporates out there that are experiencing issues 
with the way this works, i.e all of a sudden their resolvers stop recursing 
because the recursive client limit is hit.


One account I am working on, the resolvers regularly hit 20,000+ recursive 
clients when they kick of a scheduled virus scan. I wish the anti-virus vendors 
would consider the impact they are having on corporate DNS environments and 
re-think how they implement their reputation lookups, it must be the cause of 
some pretty serious ouages. :-(

Cheers,

Paul

___
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

BIND srtt algorithm not working as expected

[Paul Roberts]

Hello,


I am researching an issue we are seeing with significant volumes of DNS traffic 
being sent to non-local forwarders. I think I understand how the srtt algorithm 
works, but I am seeing more traffic going to the non-local forwarders than I 
was expecting.


To give you some context, we have 2 forwarders in the UK and 2 in Hong Kong, 
all 4 servers are responsible for outbound internet resolution. We also have a 
number of resolving servers (in the UK and Hong Kong) that have these 4 servers 
listed in their local "forwarders" statement, so I am expecting the HK 
resolvers to forward mainly to the 2 local HK forwarders, with the occasional 
query out to the 2 UK forwarders so that the rtt can be measured.


When I do a packet capture on a Hong Kong resolver, over a 5 minute period, 22% 
of all packets captured are DNS queries being forwarded to the local HK 
forwarders, and 14% of the packets captured are being sent to the UK forwarders 
- this seems high to me. I had always believed that the number of queries sent 
to non-local forwarders would be a lot lower, but from looking into this in 
detail this doesn't seem to be the case.


When I do a ping from Honk Kong, the rtt to the UK forwarders is 180-190ms, in 
contrast the local HK forwarder rtt is <1ms. I can see from dumping the cache 
on the HK resolver that the rtt is indeed much lower to the HK servers:


;   10. [srtt 478560] [flags 4000] [edns 146/5/4/4/4] [plain 
0/0] [udpsize 2448] [ttl -1033437]

;   10. [srtt 648550] [flags 4000] [edns 153/4/4/4/4] [plain 
0/0] [udpsize 2270] [ttl -1033437]

;   10. [srtt 2774590] [flags 4000] [edns 133/4/4/4/2] [plain 
0/0] [udpsize 1160] [ttl -1033437]

;   10. [srtt 3477510] [flags 4000] [edns 170/6/6/6/4] [plain 
0/0] [udpsize 1012] [ttl -1033437]


I did some digging and came across this presentation: 
https://www.nanog.org/meetings/nanog54/presentations/Tuesday/Yu.pdf


This seems to imply on slide 16 that with lower query rates, BIND 9.8 has a 
habit of sending fairly significant volumes to DNS servers with higher rtts. I 
am wondering if this is still the case in BIND 9.10 or 9.11 and whether there 
is anything that can be done about it?


In BIND 8 I think we could have used the topology statement to influence the 
behaviour but I gather that is not an option in BIND 9?


Is there a solution to this because the slow responses back from the UK are 
impacting application performance for users in HK?


We need to keep the UK servers as part of the configuration for 
failover/redundancy, removing them is not an option.


Thanks,


Paul

Paul Roberts
Calleva Networks Ltd.
Email: p...@callevanetworks.com


___
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

Re: DNSSEC and nsupdate

[Paul Kosinski]

Setting the permissions of a *private* key to 0644 sounds like a bad
idea. Maybe you mean 0640?


On Fri, 2 Mar 2018 23:28:28 +
"Prof. Dr. Michael Schefczyk"  wrote:

> Dear Mark,
> 
> I did get the issue resolved while setting up a test environment.
> 
> The issue is that normal permissions in the key-directory are
> root:bind 0644 for the public key and root:bind 0600 for the private
> key. The issue disappears when setting the private key to 0644 also
> and that must be done before starting bind - before using nsupdate is
> not enough.
> 
> Do you know if these permissions are standard or a consequence of
> starting DNSSEC via webmin?
> 
> Test setup - BIND 9.10.3-P4-Debian stretch:
> 
> /etc/bind/named.conf
> include "/etc/bind/named.conf.options";
> include "/etc/bind/named.conf.local";
> include "/etc/bind/named.conf.default-zones";
> include "/etc/bind/named.conf.log";
> key rndc-key {
>   algorithm hmac-md5;
>   secret "ctHOTtudBPhdKIgaC2baPA==";
>   };
> key nsupdate {
>   algorithm HMAC-SHA512;
>   secret
> "E0tzjpBzrcpGiZwmlqsE86hTzI2UAXNlm/pRNl2blZaze4Edn7vSHWP6
> 14gmwKKXYQPKHwnG83HTWURbqRykMQ=="; }; controls {
>   inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys
> { rndc-key; }; };
> 
> /etc/bind/named.conf.options
> options {
>   directory "/var/cache/bind";
>   dnssec-validation auto;
> 
>   auth-nxdomain no;# conform to RFC1035
> allow-recursion { any; };
> };
> 
> /etc/bind/named.conf.local
> zone "testzone.com" {
>   type master;
>   file "/var/lib/bind/testzone.com.hosts";
> update-policy  { grant nsupdate zonesub TXT; };
> key-directory "/var/lib/bind";
> auto-dnssec maintain;
>   };
> 
> Regards,
> 
> Michael Schefczyk
> 
> -Ursprüngliche Nachricht-
> Von: Mark Andrews [mailto:ma...@isc.org] 
> Gesendet: Montag, 26. Februar 2018 01:57
> An: Prof. Dr. Michael Schefczyk 
> Cc: bind-users@lists.isc.org
> Betreff: Re: DNSSEC and nsupdate
> 
> 
> > On 26 Feb 2018, at 8:12 am, Prof. Dr. Michael Schefczyk
> >  wrote:
> > 
> > Dear Mark,
> > 
> > Thank you very much! No, chroot is not involved. Package
> > debootstrap (required for chroot as far as I understand) is not
> > even installed.
> > 
> > It would be great to understand, what the error message:
> > 
> > warning: dns_dnssec_findzonekeys2: error reading private key file 
> > fqdn/ECDSAP384SHA384/41844: file not found
> > 
> > really means. One does specify the key directory. Does the error
> > message imply, that the key directory should have as many levels of
> > subdirectories as the error message contains slashes? In the lowest
> > directory level, how would a key file need to be named. Not the old
> > convention of K[fqdn]+number+keyid.key or .private anymore?
> 
> No that hasn’t changed.
> 
> error reading private key file fqdn/ECDSAP384SHA384/41844
> 
> is short hand for
> 
> error reading private key file for ‘fqdn' with algorithm
> ECDSAP384SHA384 and key id 41844.
> 
> At this stage I suggest that you post actual config details and
> actual command lines rather than describing what you have done as the
> error will be in the details which we can’t see without them.
> 
> > Regards,
> > 
> > Michael
> > 
> > Technische Universität Dresden
> > Fakultät Wirtschaftswissenschaften
> > Lehrstuhl für Entrepreneurship und Innovation Prof. Dr. Michael 
> > Schefczyk
> > D-01062 Dresden
> > 
> > Fon: +49-3 51-4 63-3 68 81
> > Fax: +49-3 51-4 63-3 68 83
> > www.gruenderlehrstuhl.de
> > 
> > 
> > 
> > 
> > Are you running chrooted? Did you make the keys visible in the
> > chroot area?
> > 
> > 
> >> On 25 Feb 2018, at 2:37 am, Prof. Dr. Michael Schefczyk
> >>  wrote:
> >> 
> >> Dear All,
> >> 
> >> For a long time already, I am using a bind master DNS server based
> >> on debian set up via webmin. It is currently Debian Stretch with
> >> bind 9.10. I am using DNSSEC.
> >> 
> >> The  webmin setup leads to all keys being stored in /var/lib/bind.
> >> The naming scheme is K[fqdn]+number+keyid.key or .private. There
> >> is one key-signing key and one zone-signing key for each fqdn.
> >> Resigning works via a perl srcipt / cronjob shipped by webmin.
> >> 
> >> To be able to generate future letsencrypt wildcard certificates, I
> >> would like to implant acme challenges as TXT records via DNS.
> >> Using nsupdate, the dnssec signing becomes troublesome. The error
> >> message in update_debug.log is:
> >> 
> >> Date/Time info: client IP#36210/key nsupdate: updating zone
> >> 'fqdn/IN': adding an RR at '_acme-challenge.fqdn' TXT "..."
> >> Date/Time error: client IP#36210/key nsupdate: updating zone
> >> 'fqdn/IN': found no active private keys, unable to generate any
> >> signatures Date/Time error: client IP#36210/key nsupdate: updating
> >> zone 'fqdn/IN': RRSIG/NSEC/NSEC3 update failed: not found
> >> 
> >> Looking 

Re: DNS performance Help when query log is off -- which default parameters will impact the DNS performance

[Paul Kosinski]

Google search for "man named" turns up:

  https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.named.html

which says (among more details):

  named [-4] [-6] [-c config-file] [-d debug-level] [-E engine-name] [-f]
[-g] [-M option] [-m flag] [-n #cpus] [-p port] [-s] [-S #max-socks]
[-t directory] [-U #listeners] [-u user] [-v] [-V] [-x cache-file]

For more explanation, look at:

  
https://kb.isc.org/article/AA-01249/0/UDP-Listeners-choosing-the-right-value-for-U-when-starting-named.html



On Thu, 22 Feb 2018 01:50:22 +
"PENG, JUNAN" <jp2...@att.com> wrote:

> Hi, Paul
> 
> UDP listeners per interface
> 
> Do you know how to modify this parameter -- UDP listeners per
> interface
> 
> version: BIND 9.10.5-S1  (Unknown)
> boot time: Tue, 13 Feb 2018 06:12:53 GMT
> last configured: Tue, 13 Feb 2018 06:12:53 GMT
> CPUs found: 4
> worker threads: 4
> UDP listeners per interface: 3
> number of zones: 102
> debug level: 0
> xfers running: 0
> xfers deferred: 0
> soa queries in progress: 0
> query logging is OFF
> recursive clients: 0/900/1000
> tcp clients: 0/15000
> server is up and running
> 
> BR
> Michael
___
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

Re: DNS performance Help when query log is off -- which default parameters will impact the DNS performance

[Paul Kosinski]

Could it be that you're network limited?

In any case, the values of the following parameters may be illuminating
(they may be obtained via "rndc status").

  CPUs found
  worker threads
  UDP listeners per interface

For example, my very lightly loaded authoritative server reports:

  version: BIND 9.10.6  (Not currently available)
  boot time: Fri, 12 Jan 2018 23:49:54 GMT
  last configured: Wed, 21 Feb 2018 05:00:02 GMT
  CPUs found: 4
  worker threads: 4
  UDP listeners per interface: 3
  number of zones: 4
  debug level: 0
  xfers running: 0
  xfers deferred: 0
  soa queries in progress: 0
  query logging is ON
  recursive clients: 0/0/1000
  tcp clients: 0/100
  server is up and running

--

On Wed, 21 Feb 2018 20:59:16 +
"PENG, JUNAN"  wrote:

> Hi, Tony
> 
> During my performance test,  I also tested the performance without
> query logs.  I disabled the query log feature , but  it seemed that
> QPS  couldn't  go higher (about 75KQPS)  when CPU still had lots of
> room  --  Named CPU Usage was about 250%,  but in theory  it can
> reach to 400% (4 vCPU).
> 
> 
> In your opinion,  which default parameters I need pay attention to ,
> which will impact system capacity performance when query log is off?
> 
> 
> Our Bind version is 9.10.5.  Do you know what version you think will
> have better multi-threading ?
> 
> 
> Thank you very much!
> 
> Michael
> 
> -Original Message-
> From: PENG, JUNAN 
> Sent: Wednesday, February 21, 2018 11:32 AM
> To: 'Tony Finch' 
> Subject: RE: Help 
> 
> Another thing:
> 
> When query log is on.
> 
> Traffic is 35k QPS,   the Named CPU usage is 260%
> Traffic is 40K QPS,  the Named CPU usage is 260% Traffic is 50K QPS,
> the Named CPU usage is 260% Traffic is 70 -100 KQPS, the named CPU
> usage is still 260% 
> 
> When the named CPU usage has a limitation 260% here ? (in theory, it
> should be 400%)
> 
> BR
> Michael
> 
> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at]
> Sent: Wednesday, February 21, 2018 11:09 AM
> To: PENG, JUNAN 
> Cc: bind-users@lists.isc.org
> Subject: Re: Help 
> 
> PENG, JUNAN  wrote:
> >
> > Why Query log off/on  feature is impacting named CPU Usage ?
> 
> It has to serialize query processing in order to write to the log,
> and that serialization barrier limits the parallelism that it can
> achieve (due to Amdahl's law).
> 
> Tony.
___
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

Re: SOA settings

[Paul Kosinski]

Speaking of units, University of Chicago Professor Nicholas Metropolis
(who had been one of the original Manhattan Project scientists at Los
Alamos) remarked that the standard lecture period of 50 minutes lasted
approximately 1 Micro-Century.


On Fri, 2 Feb 2018 17:00:10 -0500
Warren Kumari  wrote:

> On Fri, Feb 2, 2018 at 3:31 PM, Dave Warren  wrote:
> > On Fri, Feb 2, 2018, at 11:57, Warren Kumari wrote:
> >> Hopefully Lewis knows / understand that we are just squabbling
> >> amongst ourselves because we've know each other for a long time
> >> and this is in good humor.
> >
> > Yes indeed :)
> >
> >> The actual values used are open to tuning, but in the original
> >> posting, you, that was 15 seconds, and was *probably* a typo for 15
> >> minutes. I personally always use seconds in my zonefiles, and avoid
> >> the new fangled hours / weeks / syntax.
> >
> > I'm the exact other way around, I prefer content to be as human
> > readable as possible, and in my experience most humans work better
> > with smaller numbers including units (especially under
> > stress/pressure).
> 
> What?! You mean you still think in archaic units like hours and laghu
> and days and fortnights and similar?! Weird Do you measure length
> in alen? Or kyndemil?
> 
> I use seconds for *everything* -- when pointy-haired boss types ask if
> I'm actually working on a project (instead of, you know, snarking on
> mailing lists) I tell them that I've put in "more than 2834 seconds in
> the past 2 weeks alone". The arbitrary precision and large number
> makes it sound like I've done way more than, you know, less than an
> hour.
> 
> It only takes a few 2678400 seconds to get into this habit - if you
> are having a hard time adjusting, I'd recommend Kris Allen's seminal
> work - https://www.youtube.com/watch?v=PwYnG2DGbPo   [0] - this is
> only the first in a planned series; IIRC, the next one will cover the
> number of seconds needed to cook an egg to the desired yolk
> consistency, and the following one, for some unknown reason, helps you
> remember the gestation period of a muskrat.
> 
> >
> > Each to their own, obviously.
> >
> 
> Apparently.
> W
> P.S: You are welcome for the earworm.
> 
> 
> 
___
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

Re: Zone give from one second to another error...

[Paul Kosinski]

Michelle (and others who may be interested),

I have found mxtoolbox.com to be helpful in diagnosing DNS and related
problems. It is able do all kinds of DNS lookups from *outside* your
domain so you can see what your normal Internet users see. It will do
basic stuff (manually initiated) for free, and will do continual
(automated) monitoring if you pay them.


On Sun, 24 Dec 2017 07:57:08 +0200
Michelle Konzack  wrote:

> Hello Harald,
> 
> On 2017-12-24 06:26:03 Reindl Harald hacked into the keyboard:
> > https://intodns.com/24v-technic.info
> 
> This site is realy cool!
> 
> However...
> 
> > Nameserver records returned by the parent servers are:
> > dns3.tamay-dogan.net.   ['78.47.247.21'] (NO GLUE)   [TTL=86400]
> > dns2.tamay-dogan.net.   ['217.147.94.23'] (NO GLUE)   [TTL=86400]
> > dns1.tamay-dogan.net.   ['78.47.104.44'] (NO GLUE)   [TTL=86400]
> 
> ...can you explain me the thing with the GLUE?
> I do not understand this.
> How to GLUE someting?
> 
> Note:   will be removed soon, as I migrate my servers  to
> Estonia and will be reenabled as  which is  much
> shorter. I have only to convince my Registrar, that I need more then
> three DNS in the setup (this is currently a technical limitation
> @ISP).
> 
>Also 2 additional MX will be re-added...
> 
>Unfortunately I have not gotten bind9 running with PostgreSQL
> yet which is realy annoying.
> 
> Thanks
> 
___
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