[SPAM] Win2k and bind

[Greg]

I know this is a very lame question, But I have been out of the Bind loop
for a number of years ( yes I went over to the dark side ...MS DNS) but I
want to come back.  My question is this I have win2K servers what version of
bind will run on this?
 
Thanks
Greg

This message has been checked by the GDSI Barracuda SPAM/Virus Firewall.

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

BIND9 is 25 today!

[Greg Choules]

Please raise a beverage of choice and celebrate the 25th birthday of BIND9:

commit 7ee52cc7d195433bb8f55972e2a8ab29668f7bce
Date: Mon Aug 17 22:05:58 1998 +
-- 
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: Is this KB example backwards? Re: Multiple master servers for the same zones

[Greg Choules]

Doing this officially.

Firstly @Fred you were right. I skim read it knowing what I ought to see and 
didn't spot what was actually there.
Thanks for pointing it out, I'll get that fixed.

Secondly @Leroy the config is the thing that will determine what types a zone 
is.
Please would you do a few things and share results? Do the same on both servers 
and make it clear which is which. Please also use the same zones on both boxes 
as examples:
- "named -V" to see what versions each of them is running.
- "named-checkconf -px" Copy/paste just the zone definitions for a couple of 
zones you are having trouble with, as examples. Not the whole config.
- "rndc zonestatus ". Use the same zones you chose from above.

Let’s see what we see.
Cheers, Greg

> On 8 Sep 2023, at 01:24, Leroy Tennison via bind-users 
>  wrote:
> 
> Just to clarify, the configuration I was referring to was supposed to have a 
> master and slave DNS server for private zones (only two DNS servers) but 
> something happened during/after upgrade and they both showed master (actually 
> rndc -s 127.0.0.1 -r zonestatus  zones>) reported master and the other primary.
> 
> On Thursday, September 7, 2023 at 04:09:04 PM CDT, Fred Morris 
>  wrote:
> 
> 
> Hi Greg.
> 
> So somebody referenced this KB article because presumably it was 
> tangentially relevant, but I don't know that the OP is working with 
> standby infrastructure (good question!). All they say is that after an 
> upgrade all servers were masters.
> 
> The amount of direct relevance of the article is questionable. 
> Nonetheless, paragraph two seems factually incorrect on its face: changing 
> type master; to type slave; does not swich a server from secondary to 
> master, last I checked it did the opposite.
> 
> On Thu, 7 Sep 2023, Greg Choules wrote:
> > 
> > Hi Fred.
> > No, the sense is correct.
> > Imagine you have a server with a secondary zone of (say) "example.com",
> > which transfers data for that zone from a primary somewhere.
> 
> The KB article talks about multiple masters. At the outset there is no 
> secondary.
> 
> > The secondary
> > loads data received during a zone transfer straight into memory and uses it.
> > It is optional for the secondary to also write that data to a file on its
> > local storage, if you specify a "file" statement in the zone declaration.
> 
> All examples (barring questions of relevance) of configuration syntax in 
> the article specify a file statement. In one case it's implicit as in 
> masterfile-format raw; and in the other it's quite explicit (but both of 
> the examples are talking about standby primaries, which are not an 
> explicit thing in the software although they are conceptually understood).
> 
> Please re-read the second paragraph and try again.
> 
> > If the server currently being secondary for "example.com" does write that
> > zone to disc then it is easy to switch it to become primary because it
> > already has the zone file stored locally. Just change the "type", leave the
> > "file" statement alone and delete (or comment) the "primaries".
> 
> Agreed.
> 
> > Does that help?
> 
> No. I have personally set up and administered a corosync / pacemaker 
> cluster to do a standby to master promotion (for publishing RPZs with 
> BIND) in a past life.
> 
> Respectfully...
> 
> 
> --
> 
> Fred
> -- 
> 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 <mailto: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: Unhelpful startup message re: RPZ

[Greg Choules]

Hi John.
From the ARM:
response-policy
…
Blocks: options, view
Tags: server, security, query, zone
Specifies response policy zones for the view or among global options.

Blocks: says where this statement can be used; i.e. in global options or within 
a view.
The description is reasonably clear (I think) that you specify this globally 
(in options { ) if you don’t have views, or you specify it in a view along with 
the RPZ zone(s) you are defining.

Remember that as soon as you have one or more user-defined views, all zone “….” 
statements must go into them and you cannot have zones defined outside of views 
anymore - either/or. This means that if you define RPZ zones inside views then 
the corresponding “response-policy” statement(s) must also go into the same 
views.

Perhaps the log message could be a little less cryptic and yes, as Ondřej says, 
Gitlab is the place to go to request some nicer wording, or any other changes 
you think would be beneficial.

Hope that helps.
Cheers, Greg



> On 21 Sep 2023, at 17:22, John Thurston  wrote:
> 
> I just spent 4 hours* of my life trying to figure out why BIND 9.16 
> complained on startup:
> 
> 
>> rpz 'rpz.local' is not a master or slave zone
> 
> when the zone was obviously defined, and was obviously loading. This was 
> easily verified by looking at named-checkconf -px output, and by looking in 
> the logs to see the XFR from its primary.
> 
> It turns out . . . my global response-policy option worked swimmingly when 
> there was exactly one view defined. When there is more than one view, the 
> reference to the zone becomes ambiguous and bind threw out that (not very) 
> helpful message. When there is more than one view, the response-policy must 
> be specified in each relevant view.
> 
> Where do I make a 'feature request'? I think I see how to register defects 
> (GitLab). Do feature requests go there, too? I'd love to see the text of that 
> message be a little more explanatory. Maybe, "Dude. The zone you named exist, 
> but with more than one view your reference is ambiguous."
> 
> And, now that I think about it, it also feels like a defect in 
> named-checkconf that this is not called out. Or maybe I'm expecting too much 
> from named-checkconf ?
> 
> * Admittedly, the second and third hours were of diminishing value, as my 
> caffeine wore off and my frustration grew. After a night's sleep, and a pot 
> of fresh tea I figured it out.
> 
> -- 
> --
> Do things because you should, not just because you can. 
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov <mailto:john.thurs...@alaska.gov>
> Department of Administration
> State of 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

-- 
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: [help]how to configure ecs subnet for bind-9.18-21

[Greg Choules]

Hello.
Do you mean 9.18-S1?


> On 28 Apr 2024, at 08:06, Yang via bind-users  
> wrote:
> 
> 
> dear admin:
>   now, i use bind-9.18-21, i want to use ecs client subnet function; but i 
> don't know how to configure it, and i don't get method from google
>   please give me some example,or document , or google links to learn about it 
> ;
>   thanks!
>   
> Yang
> 395096...@qq.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: [help]how to configure ecs subnet for bind-9.18-21

[Greg Choules]

OK.

Firstly, the bad news. ECS is only available in the subscription version of 
BIND. That is, versions ending with -S. To get this version you need a (paid) 
support contract with ISC. If you are interested, let me know.

Secondly, 9.18.21 is not current. I would recommend that you use the latest 
version, which is 9.18.26 (you can see in your screenshot).

I hope that helps.
Greg

> On 28 Apr 2024, at 08:42, Yang <395096...@qq.com> wrote:
> 
> 
> 
> is v.9.18.21 below this reference
> 

> 
> 
>   
> Yang
> 395096...@qq.com
>  
> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=Yang&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287&mail=395096713%40qq.com&code=>
>  
> 
> 
> -- Original --
> From: "Greg Choules" ;
> Date: Sun, Apr 28, 2024 03:39 PM
> To: "Yang"<395096...@qq.com>;
> Cc: "bind-users";
> Subject: Re: [help]how to configure ecs subnet for bind-9.18-21
> 
> Hello.
> Do you mean 9.18-S1?
> 
> 
>> On 28 Apr 2024, at 08:06, Yang via bind-users  
>> wrote:
>> 
>> 
>> dear admin:
>>   now, i use bind-9.18-21, i want to use ecs client subnet function; but i 
>> don't know how to configure it, and i don't get method from google
>>   please give me some example,or document , or google links to learn about 
>> it ;
>>   thanks!
>>  
>> Yang
>> 395096...@qq.com
>>  
>> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=Yang&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287&mail=395096713%40qq.com&code=>--
>>  
>> 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: Make dig and nslookup DNSSEC aware?

[Greg Choules]

Odd numbers (9.17, 9.19…) are the development versions. Even numbers (9.18, 
9.20 - soon…) are the production versions, based on the odd-numbered version 
before.
So 9.18.27 (currently) would be the one to go for.

Cheers, Greg

> On 22 May 2024, at 16:53, Robert Wagner  wrote:
> 
> https://www.isc.org/blogs/bind-doh-update-2021/   
> BIND DoH Update <https://www.isc.org/blogs/bind-doh-update-2021/>
> Status of DNS-over-HTTPS support in BIND 9 as of March, 2021 The latest 
> development release of BIND 9 contains a significant number of improvements 
> to DNS-over-HTTP (DoH).
> www.isc.org <http://www.isc.org/>
> 
> It looks like +https was added in version 9.17 I just need to get RedHat 
> to start using it
> 
> RW
> From: bind-users  <mailto:bind-users-boun...@lists.isc.org>> on behalf of Havard Eidnes via 
> bind-users mailto:bind-users@lists.isc.org>>
> Sent: Wednesday, May 22, 2024 11:47 AM
> To: don.frie...@gov.bc.ca <mailto:don.frie...@gov.bc.ca> 
> mailto:don.frie...@gov.bc.ca>>
> Cc: ond...@isc.org <mailto:ond...@isc.org>  <mailto:ond...@isc.org>>; bind-users@lists.isc.org 
> <mailto:bind-users@lists.isc.org>  <mailto:bind-users@lists.isc.org>>
> Subject: Re: Make dig and nslookup DNSSEC aware?
>  
> This email originated from outside of TESLA
> 
> Do not click links or open attachments unless you recognize the sender and 
> know the content is safe.
> 
> >   Doesn't dig already offer DoT using +tls and DoH using +https?
> 
> You're right, it does.
> 
> I need to sort out my $PATH...
> 
> Regards,
> 
> - Håvard
> --
> 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 <mailto: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 <mailto: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: forward option in dns server

[Greg Sloop]

I have a similar setup, and I do it the way that Greg Choules suggests.

I could probably dig up the exact way I have BIND configured, but the
function is like this:
Clients query the non-AD BIND servers, for *all* queries. For the AD zone,
we use something like this; Our first level domain, lets assume is
example.com. All domain resources are in ad.example.com. So we configure
the non AD BIND servers to send queries for *.ad.example.com to the AD
servers.

So, in this way, the non-AD BIND servers handle all queries, but they
forward queries for ad.example,com to the AD name servers and return the
results.

I can't tell from the OP if they are using Samba or something else - but
we're using Samba in the example above. Samba has a couple of options for
their name server, an "internal" name server and a BIND version. Both can
be configured to forward any queries they aren't authoritative for to
another server. However, IIRC, at least the internal one can't handle large
loads. And while we'd probably be fine using it as our "primary" name
server, it seems needlessly risky.

I'd much rather have a well understood and mainstream BIND server as the
"front-line" server and then only forward queries for the AD zones to the
AD servers. (If you have some odd issue with a query outside the AD server
you can have a much larger support base, here, to help understand and fix
the issue.)

YMMV, but this was the way we decided to handle it after quite a bit of
consideration.
I hope that's helpful, though perhaps straying slightly off-topic for the
list.



On Thu, Jun 27, 2024 at 1:16 PM Greg Choules via bind-users <
bind-users@lists.isc.org> wrote:

> Hi Renzo.
> Ah OK, I had it the wrong way round. AD DNS needs to resolve names in the
> Internet on behalf of its clients, so it forwards to BIND.
>
> In that case, two questions:
> 1) What version of BIND are you running? You can get this with "named -V"
> 2) What is in the file "named.ca"?
> For a long time (which is why I need to know the version) BIND has had the
> Internet root hints built in, so you don't need a hint zone anymore. Unless
> you are defining different roots for some reason. Hence why I need to know
> the contents of that file.
>
> Thanks, Greg
>
>
>
> On Thu, 27 Jun 2024 at 18:06, Renzo Marengo 
> wrote:
>
>>
>> Hi Greg,
>>
>> thank you very much for your explanation.
>>
>> Let’s supposte AD domain was ‘my domain.it’  and I have 6000 computers
>> of government institute.
>>
>> Here my bind configuration:
>>
>>
>> named.conf
>>
>> ———
>>
>> include “…. named.conf.options" ;
>>
>> zone "." IN {
>>
>> type hint;
>>
>> file "named.ca";
>>
>> };
>>
>> include “…. named.rfc1912.zones";
>>
>> include “….  named.root.key";
>>
>> ———
>>
>>
>>
>> named.conf.options
>>
>> ———
>>
>> logging {
>>
>> channel named_debug {
>>
>> syslog local6;
>>
>> severity debug 1;
>>
>> print-category yes;
>>
>> print-severity yes;
>>
>> print-time yes;
>>
>> };
>>
>> category default { named_debug; };
>>
>> };
>>
>>
>> options {
>>
>> auth-nxdomain no;# conform to RFC1035
>>
>> allow-recursion {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ;
>>
>> allow-query   {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ;
>>
>> recursive-clients 3000;
>>
>> allow-query-cache {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>> ….. } ; ;
>>
>>
>> listen-on port 53 { 127.0.0.1; A.B.C.D; };
>>
>> directory “….. named";
>>
>> dump-file “….. cache_dump.db";
>>
>> statistics-file “….. named_stats.txt";
>>
>> memstatistics-file “…. named_mem_stats.txt";
>>
>> recursing-file  “… named.recursing";
>>
>> secroots-file   “… named.secroots";
>>
>> recursion yes;
>>
>> dnssec-enable no;
>>
>> dnssec-validation no;
>>
>>
>> bindkeys-file "….. named.iscdlv.key";
>>
>> managed-keys-directory "….. dynamic";
>>
>> pid-file "….. named.pid";
>>
>> session-keyfile "….. session.key";
>>
>> ———
>>
>>
>>
>> >Thirdly, I would not forward to AD D

Re: netstat showing multiple lines for each listening socket

[Greg Choules]

I’m afraid we’re a little out of sync between the documentation and the code, 
depending on which code you’re running.

-U was changed some time ago to mean the number of dispatchers to use for 
outgoing queries, not listeners to use for incoming queries. Post 9.18 it won’t 
do anything at all, so best to ignore it. We will document this properly!

-n sets the number of event loops. You can tweak this manually if you find that 
the autodetected value is not suitable for your environment and usage.

I hope that helps.
Greg


> On 10 Jul 2024, at 15:43, Thomas Hungenberg via bind-users 
>  wrote:
> 
> On 10.07.24 14:20, Tom Marcoen (EXT) wrote:
>> My server has four (virtual; it runs on vSphere) CPUs and also shows four 
>> lines in `ss` output.
>> The `ps` command shows the `-U` which - I assume - is set automatically 
>> triggered by the number of CPUs.
>> # ps -elf | grep named
>> 5 S named23769 1  9  80   0 - 251941 do_sig 07:12 ?   00:39:02 
>> /usr/local/sbin/named -U4 -u named -c /usr/local/etc/namedb/named.conf
> 
> The manpage says:
> 
>   -U #listeners
>  This option tells named the number of #listeners worker  threads
>  to  listen  on, for incoming UDP packets on each address. If not
>  specified, named calculates a default value based on the  number
>  of  detected  CPUs: 1 for 1 CPU, and the number of detected CPUs
>  minus one for machines with more than 1 CPU.
> 
> 
> So if not specified, the value of "-U" should be set to 3 with four CPUs.
> Also, the parameter "-U" usually does not show up in the ps output if not 
> specified.
> 
> So in your case it looks more like named is specifically started with "-U4"?
> 
> 
>- Thomas
> 
> -- 
> 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 9.16.1 failing assertion

[Greg Rivers]

> Yup, that borked our entire environment today. Shame on my for not testing
> in non-prod first :(
> 
> Fell back to 9.14 on FreeBSD for now.
> 
Note that the libuv issue was seen (and fixed) on FreeBSD -CURRENT recently: 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245653>. I'm not aware of a 
libuv fix for Linux yet.

Running both FreeBSD _and_ Linux is a good idea. Among other things, it's an 
excellent way to provide maximum availability for DNS.

-- 
Greg Rivers


___
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 suddenly starts responding clients with servfail

[Greg Rivers]

On Monday, 27 April 2020 03:59:39 CDT Søren Andersen wrote:
> I'm running a few BIND servers, but lately one of my servers suddenly starts
> responding to clients with servfail for every request from the clients, and
> BIND doesn't respond to the rndc or statistics interface anymore.
> 
> My logs for client-channel show me this:
> 25-Apr-2020 21:52:04.501 client @XX XX.37#2921 (google.dk): no more
> recursive clients (1000/900/1000): quota reached
> 
> I've removed all the dns traffic from the server, and the quota is still
> reached after 6+ hours?
> 
> Do you guys have some clue what all this is about? - Or any suggestions
> where to look for any further information?
> 
> I'm running BIND 9.16.1 on CentOS 7:
>
I've had the very same thing happen twice in the past two weeks on different 
production recursive servers running BIND 9.16.2 on FreeBSD. I've opened a 
ticket with ISC, and they are looking into it. Can you share any additional 
information that might aid troubleshooting?

If anyone else experiences this, please report it.

-- 
Greg


___
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 suddenly starts responding clients with servfail

[Greg Rivers]

On Friday, 8 May 2020 16:27:35 CDT Søren Andersen wrote:
> I'm glad what I'm not the only one having this issue. Currently i've not
> more information that are not already mention in this mail thread.
> 
> But do you have a link to the ticket you have created?
>
<https://gitlab.isc.org/isc-projects/bind9/-/issues/1859>

-- 
Greg


___
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.1 memory leak?

[Greg Rivers]

On Friday, 17 April 2020 08:45:16 CDT Steinar Haug wrote:
> We have what appears to be a significant memory leak in BIND-9.16.1.
> 
> Environment:
>  FreeBSD 12.1-STABLE.
>  BIND-9.16.1 installed from packages.
>  Also uses libuv-1.35.0 installed from packages.
>  Authoritative only.
>  Around 800 zones of varying sizes. DNSSEC in use.
> 
https://gitlab.isc.org/isc-projects/bind9/-/issues/1893

-- 
Greg


___
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

Reverse zone reformatting after nsupdate execution

[Greg Donohoe]

Hello. I am hoping that someone can help me to figure out the cause of an
issue I am seeing when running nsupdate on my BIND9 server.
Below you will find all the the details as to how my server is configured
and also the nsupdate commands that I am running.

The issue I am seeing is that I have configured a /16 10.10.in-addr.arpa
reverse zone, however when I execute nsupdate the 10.10.in-addr.arpa.dns
zone file re formats the $ORIGIN to a /24 156.10.10.in-addr.arpa.
This appears to be an issue with nsupdate rather than BIND itself as I can
manually amend the 10.10.in-addr.arpa.dns zone file whcih always remains in
a /16 format.

Please see below for details and if you need any further information please
let me know.

###
named.conf
###
greg@hp-linux:/etc/bind$ cat named.conf
##  OPTIONS
options {
directory "/var/cache/bind";

recursion no;
listen-on port 53 { any; };
allow-query  { any; };
allow-update { any; };

forwarders {
10.10.8.120;
10.196.207.11;
};

dnssec-validation auto;

auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};


## ZONES
# Zone statement for forward DNS lookups
zone "example.com" IN {
type master;
file "/etc/bind/master/example.com.dns";
allow-update { any; };
};
zone "10.10.in-addr.arpa"  IN  {
type master;
file "/etc/bind/master/10.10.in-addr.arpa.dns";
allow-update { any; };
};

###
The batch.txt file I use to run nsupdate
###
server 127.0.0.1
zone example.com
update add test.example.com 86400 IN A 10.10.156.37
send
server 127.0.0.1
zone 10.10.in-addr.arpa.
update add 37.156.10.10.in-addr.arpa. 86400 IN PTR test.example.com
send
server 127.0.0.1
zone example.com
update add test1.example.com 86400 IN A 10.10.156.38
send
server 127.0.0.1
zone 10.10.in-addr.arpa.
update add 38.156.10.10.in-addr.arpa. 86400 IN PTR test1.example.com
send

##
nsupdate debug output
##
greg@hp-linux:/etc/bind/master$ nsupdate -D -v batch1.txt
setup_system()
reset_system()
user_interaction()
do_next_command()
do_next_command()
do_next_command()
evaluate_update()
update_addordelete()
do_next_command()
start_update()
send_update()
Sending update to 127.0.0.1#53
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  15755
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0
;; ZONE SECTION:
;example.com. IN SOA

;; UPDATE SECTION:
test.example.com. 86400 IN A 10.10.156.37

update_completed()
show_message()

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  15755
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;example.com. IN SOA

done_update()
reset_system()
user_interaction()
do_next_command()
do_next_command()
do_next_command()
evaluate_update()
update_addordelete()
do_next_command()
start_update()
send_update()
Sending update to 127.0.0.1#53
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  38067
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0
;; ZONE SECTION:
;10.10.in-addr.arpa. IN SOA

;; UPDATE SECTION:
37.156.10.10.in-addr.arpa. 86400 IN PTR test.example.com.

update_completed()
show_message()

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  38067
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;10.10.in-addr.arpa. IN SOA

done_update()
reset_system()
user_interaction()
do_next_command()
do_next_command()
do_next_command()
evaluate_update()
update_addordelete()
do_next_command()
start_update()
send_update()
Sending update to 127.0.0.1#53
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  22045
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0
;; ZONE SECTION:
;example.com. IN SOA

;; UPDATE SECTION:
test1.example.com. 86400 IN A 10.10.156.38

update_completed()
show_message()

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  22045
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;example.com. IN SOA

done_update()
reset_system()
user_interaction()
do_next_command()
do_next_command()
do_next_command()
evaluate_update()
update_addordelete()
do_next_command()
start_update()
send_update()
Sending update to 127.0.0.1#53
show_message()
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:   7571
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0
;; ZONE SECTION:
;10.10.in-addr.arpa. IN SOA

;; UPDATE SECTION:
38.156.10.10.in-addr.arpa. 86400 IN PTR test1.example.com.

update_completed()
show_message()

Reply from update query:
;; ->>

Fwd: Reverse zone reformatting after nsupdate execution

[Greg Donohoe]

Adding mailing list for archiving.

-- Forwarded message -
From: Greg Donohoe 
Date: Wed, Jan 27, 2021 at 6:11 PM
Subject: Re: Reverse zone reformatting after nsupdate execution
To: Chris Isaksen 


Thank you very much for your reply Chris. Changing the masterfile-style has
addressed our issue.
I need to do more testing but so far it looks good :-)

Thanks again.

Rgds,
Greg.

On Wed, Jan 27, 2021 at 1:32 PM Chris Isaksen 
wrote:

>
>
> --
> *From:* bind-users  on behalf of Ondřej
> Surý 
> *Sent:* Wednesday, January 27, 2021 8:29 AM
> *To:* Greg Donohoe 
> *Cc:* bind-users@lists.isc.org 
> *Subject:* Re: Reverse zone reformatting after nsupdate execution
>
> You might want to change `masterfile-style` configuration option:
>
>
> https://bind9.readthedocs.io/en/latest/reference.html?highlight=masterfile-style#tuning
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> > On 27. 1. 2021, at 14:23, Ondřej Surý  wrote:
> >
> > Greg,
> >
> > there’s nothing wrong with the zone contents. $ORIGIN means “now append
> this to every name not ending with dot”.
> >
> > Ondřej
> > --
> > Ondřej Surý — ISC (He/Him)
> >
> >> On 27. 1. 2021, at 14:06, Greg Donohoe  wrote:
> >>
> >> 
> >> Hello. I am hoping that someone can help me to figure out the cause of
> an issue I am seeing when running nsupdate on my BIND9 server.
> >> Below you will find all the the details as to how my server is
> configured and also the nsupdate commands that I am running.
> >>
> >> The issue I am seeing is that I have configured a /16
> 10.10.in-addr.arpa reverse zone, however when I execute nsupdate the
> 10.10.in-addr.arpa.dns zone file re formats the $ORIGIN to a /24
> 156.10.10.in-addr.arpa.
> >> This appears to be an issue with nsupdate rather than BIND itself as I
> can manually amend the 10.10.in-addr.arpa.dns zone file whcih always
> remains in a /16 format.
> >>
> >> Please see below for details and if you need any further information
> please let me know.
> >>
> >> ###
> >> named.conf
> >> ###
> >> greg@hp-linux:/etc/bind$ cat named.conf
> >> ##  OPTIONS
> >> options {
> >> directory "/var/cache/bind";
> >>
> >> recursion no;
> >> listen-on port 53 { any; };
> >> allow-query  { any; };
> >> allow-update { any; };
> >>
> >> forwarders {
> >> 10.10.8.120;
> >> 10.196.207.11;
> >> };
> >>
> >> dnssec-validation auto;
> >>
> >> auth-nxdomain no;# conform to RFC1035
> >> listen-on-v6 { any; };
> >> };
> >>
> >>
> >> ## ZONES
> >> # Zone statement for forward DNS lookups
> >> zone "example.com" IN {
> >> type master;
> >> file "/etc/bind/master/example.com.dns";
> >> allow-update { any; };
> >> };
> >> zone "10.10.in-addr.arpa"  IN  {
> >> type master;
> >> file "/etc/bind/master/10.10.in-addr.arpa.dns";
> >> allow-update { any; };
> >> };
> >>
> >> ###
> >> The batch.txt file I use to run nsupdate
> >> ###
> >> server 127.0.0.1
> >> zone example.com
> >> update add test.example.com 86400 IN A 10.10.156.37
> >> send
> >> server 127.0.0.1
> >> zone 10.10.in-addr.arpa.
> >> update add 37.156.10.10.in-addr.arpa. 86400 IN PTR test.example.com
> >> send
> >> server 127.0.0.1
> >> zone example.com
> >> update add test1.example.com 86400 IN A 10.10.156.38
> >> send
> >> server 127.0.0.1
> >> zone 10.10.in-addr.arpa.
> >> update add 38.156.10.10.in-addr.arpa. 86400 IN PTR test1.example.com
> >> send
> >>
> >> ##
> >> nsupdate debug output
> >> ##
> >> greg@hp-linux:/etc/bind/master$ nsupdate -D -v batch1.txt
> >> setup_system()
> >> reset_system()
> >> user_interaction()
> >> do_next_command()
> >> do_next_command()
> >> do_next_command()
> >> evaluate_update()
> >> update_addordelete()
> >> do_next_command()
> >> start_update()
> >> send_update()
> >> Sending upda

Using RNDC to control remote access to my BIND server

[Greg Donohoe]

Hello,
I have created a CI/CD pipeline in order to amend zone files using nsupdate
based on a front end user request. This portion of the pipeline is working
as expected so now I want to be able to connect from my pipeline runner to
my remote BIND staging server and update the zone files on there with my
newly updated zone file.
I initially thought about using ssh from the runner to the remote BIND
server but this may not be the most secure way of connecting.
So my question is: Is it possible to use RNDC to manage my connection from
host to remote server and if so, how can I ensure complete security?

All input greatly appreciated.
Thanks.
Greg.
___
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

[Greg Donohoe]

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.

Rgds,
Greg.




On Thu, Apr 22, 2021 at 8:38 PM Tony Finch  wrote:

> Greg Donohoe  wrote:
>
> > I have created a CI/CD pipeline in order to amend zone files using
> nsupdate
> > based on a front end user request. This portion of the pipeline is
> working
> > as expected so now I want to be able to connect from my pipeline runner
> to
> > my remote BIND staging server and update the zone files on there with my
> > newly updated zone file.
>
> If you want to make the same change on the remote server that you made
> locally, can't you use nsupdate again but point it at the remote server?
> Or is there something more complicated going on?
>
> Use ddns-keygen to create a TSIG authentication key and add the key to the
> allow-update ACL on the remote server.
>
> (You can also add your own TSIG keys to allow remote control with `rndc
> -s`, but it sounds to me like rndc is a red herring.)
>
> There's also my `nsdiff` program https://dotat.at/prog/nsdiff/
> which can make a zone on a remote server look like a local zone
> file using nsupdate.
>
> Tony.
> --
> f.anthony.n.finchhttps://dotat.at/
> North Utsire, South Utsire: Northerly or northwesterly 4 to 6,
> occasionally 7 at first in eastern South Utsire. Rough at first in
> eastern South Utsire, otherwise moderate. Showers. Good.
>
>
___
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

[Greg Donohoe]

Thanks for the input Anand.
Yes there is still some confusion on my part as to which option to use to
best fir my current environment.
In regards to the nsupdate, what is the best way to secure the connection,
so to ensure that only my local server can make the amendments to the
remote server named & zone files?
I dont want anyone/anything else other than my local machine to make any
changes on my remote BIND server.

Rgds,
Greg.

On Fri, Apr 23, 2021 at 11:21 AM 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: Using RNDC to control remote access to my BIND server

[Greg Donohoe]

Thanks Anand.
When using this TSIG solution is the key visible (clear) within the DNS
packet being sent to the remote server or is it encrypted?
Is this communication secure? eg if someone is sitting on the wire sniffing
the packets, would they be able to extract the key ?
Or is the security of the communication done through the ACL and the key is
TSIG only used to allow me to make changes to the zone file?
The main reason why I was leaning towards SSH was to try to ensure that all
communication between local & remote was encrypted.

Rgds,
Greg.

On Fri, Apr 23, 2021 at 2:21 PM Anand Buddhdev  wrote:

> On 23/04/2021 14:24, Greg Donohoe wrote:
>
> Hi Greg,
>
> > In regards to the nsupdate, what is the best way to secure the
> connection,
> > so to ensure that only my local server can make the amendments to the
> > remote server named & zone files?
> > I dont want anyone/anything else other than my local machine to make any
> > changes on my remote BIND server.
>
> You should create a TSIG key, and configure the zones on the remote
> server to only accept dynamic DNS updates signed by this key. And then
> use this key with nsupdate when sending your updates. Check the man page
> of nsupdate and look at the '-k' and '-y' options for using tsig keys.
>
> You can additionally also configure your remote BIND to accept updates
> only from certain IP addresses. For details on how to configure this,
> please read the excellent documentation (especially section 4.2.29 and
> the "allow-update" option):
>
> https://bind9.readthedocs.io/en/v9_16/
>
> Regards,
> Anand Buddhdev
>
___
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

[Greg Donohoe]

Thank you for the excellent advise, it is a lot clearer to me now.
I am checking the nsupdate & TSIG man pages for additional knowledge.
Outside of these man pages , are there any other references
(tutorials/videos) that you would recommend?
Particularly around the area of TSIG key generation & management best
practices?

Rgds,
Greg.

On Mon, Apr 26, 2021 at 4:16 PM Tony Finch  wrote:

> Anand Buddhdev  wrote:
> >
>
> Anand's advice is good, as usual :-)
>
> But a small pedantic point:
>
> > The DNS protocol itself has recently been updated to allow for
> > encryption, using DTLS (DNS-over-TLS).
>
> DTLS usually means "datagram TLS", i.e. TLS-over-UDP (RFC 6347). There's a
> spec for DNS-over-DTLS (RFC 8094) but I have not seen much enthusiasm for
> deploying it: DTLS combines all the disadvantages of UDP with all the
> disadvantages of TLS. (Or worse: DTLS has a more complicated state machine
> than normal TLS so there have been a bunch of DTLS-specific
> vulnerabilities which makes me very reluctant to deploy it.)
>
> There is a lot more enthusiasm for DNS-over-TLS (aka DoT) and
> DNS-over-HTTPS (aka DoH), and maybe in the future DNS-over-QUIC.
>
> But right now, none of these are particularly easy to get working as
> transports for UPDATE, and as Anand said, it usually isn't necessary.
>
> I'm looking forward to zone transfers over TLS, because public key
> authentication (with client certificates) is a bit easier to deploy
> between different organizations than TSIG secret key authentication.
> There's not such a clear benefit for UPDATE-over-TLS where I'm sitting,
> apart from the neatness of having all authenticated traffic over TLS.
>
> Tony.
> --
> f.anthony.n.finchhttps://dotat.at/
> Bailey: Northeast 5 to 7. Moderate or rough. Showers at first. Good.
>
>
___
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

test - ignore

[Greg Choules]

Hello.
___
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

CVE-2022-2795

[Greg Rabil]

Hi bind-users,
This vulnerability was recently fixed in BIND 9.16.33:

CVE-2022-2795: Processing large delegations may severely degrade resolver 
performance

Question: Would a server that is configured to forward all queries be impacted 
by this issue?

Thanks,
Greg
-- 
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: repository for zone files

[Greg Whynott]

they (the distro maintainers) could not agree to put anything in the same place 
if the worlds sanity depended on it.

/var/named
/srv/bind
/etc/bind
/var/lib/named
/usr/local/named

it's all over the place.   myself i just create links from /var/named (which is 
where I think it was found on most commercial UNIX's I've used,  IRIX admin 
here..) to wherever they decided to stick it.  That being said,  if you build 
it from source (which I'd be inclined to do if not using a linux wiht a support 
contract),  you can pass the path to configure and place it anywhere you wish 
with zero functionally loss.

its a bunch of "my way makes sense,  i'll pee in this corner,  its mine now).

its UNIX fragmentation all over again.  8)



-g



On Sep 23, 2010, at 4:01 PM, Michael Sinatra wrote:

> On 09/23/10 12:53, Stewart Dean wrote:
>> On AIX, I'm used to /etc/dns.  CentOS seems to place in /var/named.  Is
>> there any blessed, bestofallpossibleworlds place for the zone files. I'm
>> moving our DNS from from AIX to CentOS/Fedora. I'm inclined to create
>> the /etc/dns dir but maybe it'd be better to put it in
>> /var/named.Comments, brickbats?
> 
> I have always found it to be a good idea to do what the OS wants.  Many 
> OSes now are set up to run bind in a chroot jail (a good thing), but 
> this requires a specific directory structure.  If your OS has already 
> set that up (and if the startup scripts work with that structure), then 
> it's best to keep them that way.  Probably the ideal thing to do is use 
> the OS defaults and then symlink your previous directory structure to 
> the OS defaults as necessary to maintain compatibility with your 
> in-house scripts and processes.
> 
> michael
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

RE: Unable to query the nameserver

[Greg Whynott]

someone with way more bind clues than I would be able to give you a better 
answer.the error returned begs two questions..

1. is this server behind or running a local firewall?
2. is bind actually listening on the proper interface?

you could confirm #2 by typing 'nslookup ns1.example.de 1.1.1.1'  where 1.1.1.1 
is the ip of the local machine(you could even do this on another machine,  its 
telling the resolver to use 1.1.1.1 as the name server for initial queries,  if 
it works internally,  try an exterior machine to run the command on).  it 
should return your A RR.  also you could try typing " netstat -an | grep \:53\ 
| grep LIST " and see if its listening on the proper interface.  

do the logs complain about any zones?  something like "not loading zone X"..

good luck with things,
-g



From:
Sent: Monday, October 04, 2010 5:08 PM
To: bind-users@lists.isc.org
Subject: Unable to query the nameserver

I am configuring BIND on two servers: ns1.example.de on a server with
IP address 1.1.1.1 and ns2.example.de on a server with IP address
1.1.2.2. BIND starts fine on both servers, but when I try to configure
my domain name in the registrar's control panel I get this error:
"""
Error : Unable to query the nameserver ns1.example.de
"""

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

Re: Unable to query the nameserver

[Greg Whynott]

its as if they think hackers main source of targets comes from here.doesn't 
appear to really want any help anyway.  

-g



On Oct 4, 2010, at 8:35 PM, Noel Butler wrote:

> On Mon, 2010-10-04 at 17:29 -0500, Lyle Giese wrote:
>> Dotan Cohen wrote: 
> 
>>> The ports aren't blocked as another site (example.eu) hosted on the
>>> 1.1.1.1 server works fine. The working site has both nameservers
>>> pointed to that same server (on two different IP addresses on eth0 and
>>> etho0:0). Only the example.de site which has one nameserver on the
>>> 1.1.1.1 machine and the second nameserver on 1.1.2.2 is giving me a
>>> headache.
>>> 
>>> 
>>>   
>> I would like to help but since you are refusing to post the real ip address 
>> or the real hostnames or the real domain names involved, I can not.  I could 
>> do some testing from here to see if your firewall was configured correctly 
>> or what the view was from outside your network.  But I can not.  
>> 
> 
> Quite right, too many people with paranoia come here looking for help but 
> refuse to let us do correct remote testing.
> First post was 7.08am local, its 3 /12 hours later and we still have no real 
> info, had it been supplied his problem may been identified and resolved 3 
> hours ago.
> 
> 
> 

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

Re: Black berry

[Greg Whynott]

i'm wondering if domain.net and ns1.nameserver.net are defaults which haven't 
been configured yet.  but he is a senior sysadmin, i'm sure he considered that 
already…

-g


On Dec 7, 2010, at 7:37 AM, Matus UHLAR - fantomas wrote:

> On 07.12.10 11:06, Ejaz wrote:
>> We have problem in sending mail emails when using black berry device,
>> problem is like user cannot send emails either inside or outside the domain
>> when some one connected to our ISP and use our DNS server,
>>
>> Does it require any special configuration of bind in named.conf file for
>> the blackberry users?
>
> no. You only must configure DNS properly.
>
>> The following message to <  x...@domain.net> was
>> undeliverable.
>> The reason for the problem:
>> 5.4.7 - Delivery expired (message too old) 'DNS Soft Error looking up
>> domain.net (MX) while asking ns1.nameserver.net. Error was: unable to reach
>> nameserver on any valid IP'
>
> And you must count with the fact that with blackberry, your mail is not
> coming from your internal network, so your mailservers have to be reachable
> from the internet, or at least from blackberry IP ranges.
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> 2B|!2B, that's a question!
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


--

This message and any attachments may contain confidential and/or privileged 
information for the sole use of the intended recipient. Any review or 
distribution by anyone other than the person for whom it was originally 
intended is strictly prohibited. If you have received this message in error, 
please contact the sender and delete all copies. Opinions, conclusions or other 
information contained in this message may not be that of the organization.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

TSIG fails intermittently but dig works

[Greg Kuechle]

Hi,

I have two servers each running bind 9.7.0. I have TSIG setup on the 
servers. I upgraded the hardware on the primary server. The IPs and the 
config remained the same.
I upgrade BIND from 9.4.3-P3 to 9.7.0 at the same time on the primary.

Prior to the hardware/BIND upgrade TSIG worked good. 

The new primary is running on a sun T5120 with Solaris 10.
The older secondary is running on a sun v250 with Solaris 8.


Now it fails on some zones and works on others. If I use dig to do a zone 
transfer all zones  transfer ok.

Here is the syntax I use:
dig -y st-dns-key: @142.163.211.10 ips.com<-- this works 
only with dig, named will  not transfer.
dig -y st-dns-key: @142.163.211.10 zazu.com <-- this works 
with dig and named will transfer. 


 Logs from secondary trying to transfer the 
zones ___
Here is a zone that works:
25-Mar-2010 12:25:23.058 general: info: zone zazu.ca/IN: Transfer started.
25-Mar-2010 12:25:23.065 xfer-in: info: transfer of 'zazu.ca/IN' from 
142.163.211.10#53: connected using 142.163.20.10#56583
25-Mar-2010 12:25:23.105 general: info: zone zazu.ca/IN: transferred 
serial 2007052406: TSIG 'st-dns-key'
25-Mar-2010 12:25:23.106 xfer-in: info: transfer of 'zazu.ca/IN' from 
142.163.211.10#53: Transfer completed: 1 messages, 14 records, 482 bytes, 
0.040 secs (12050 bytes/sec)

This zone will not transfer
25-Mar-2010 12:23:28.029 notify: info: client 142.163.211.10#37594: 
received notify for zone 'ips.com': TSIG 'st-dns-key'
25-Mar-2010 12:23:28.041 general: info: zone ips.com/IN: refresh: failure 
trying master 142.163.211.10#53 (source 0.0.0.0#0): tsig verify failure

Both servers are using ntp and are the time is synced up.

I have thousands of zones most of them will transfer to the secondary.

I have tried many things with no luck(my secondary was running an older 
version of bind so I upgraded it)


Any help would be appreciated.



 Greg Kuechle



Sorry about the notice appended to the email 


NOTICE: This confidential e-mail message is only for the intended 
recipient(s). If you are not the intended recipient, be advised that 
disclosing, copying, distributing, or any other use of this message, is 
strictly prohibited. In such case, please destroy this message and notify 
the sender.___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Load Balancer for DNS

[Greg Kuechle]

Hi Sasa,

For load balancing caching DNSs, you should try using anycast. When using 
loadbalancers you may(I did) run into capacity issues.

Take a look at the quagga software package. It works great for load 
balancing.

I have used both switches and anycast, and anycast is the way to go. Using 
anycast is cheaper than buying a load balancing switch, quagga is free.

Greg.





From:   sasa sasa 
To: bind dns 
Date:   04/05/2010 12:07 AM
Subject:Load Balancer for DNS
Sent by:
bind-users-bounces+greg.kuechle=sasktel.sk...@lists.isc.org



Hello everyone,

Any one used any load balancer for DNSs? any recommendation? it's 2 
caching-only DNSs, and I'd like to make a load balance between them using 
software.

best regards,
Sasa

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



NOTICE: This confidential e-mail message is only for the intended 
recipient(s). If you are not the intended recipient, be advised that 
disclosing, copying, distributing, or any other use of this message, is 
strictly prohibited. In such case, please destroy this message and notify 
the sender.___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[no subject]

[Greg Whynott]

Hello,

I'm seeing an unfamiliar error while attempting to start a newly built from 
source named instance.   I've search on the net and within the bind-user list 
without luck,  DST returns lots of hits,  but nothing with "named DST". 
hoping someone here might know what its about.  Is it really a Day Light 
related?  
thanks much for your time,
greg




the error:

[r...@fido ~]# /etc/init.d/named start
Starting named:[FAILED]
[r...@fido ~]# grep named /var/log/messages 
Jun 13 10:20:00 fido named[2430]: starting BIND 9.7.0-P2 -u named
Jun 13 10:20:00 fido named[2430]: built with '--build=i386-redhat-linux-gnu' 
'--host=i386-redhat-linux-gnu' '--program-prefix=' 
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' 
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' 
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' 
'--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' 
'--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' 
'--disable-static' '--disable-openssl-version-check' 
'--with-pkcs11=/usr/lib/pkcs11/PKCS11_API.so' '--with-dlz-filesystem=yes' 
'--with-gssapi=yes' '--disable-isc-spnego' 'build_alias=i386-redhat-linux-gnu' 
'host_alias=i386-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables' 'CPPFLAGS= -DDIG_SIGCHASE'
Jun 13 10:20:00 fido named[2430]: adjusted limit on open files from 1024 to 
1048576
Jun 13 10:20:00 fido named[2430]: found 2 CPUs, using 2 worker threads
Jun 13 10:20:00 fido named[2430]: using up to 4096 sockets

Jun 13 10:20:00 fido named[2430]: initializing DST: no engine
Jun 13 10:20:00 fido named[2430]: exiting (due to fatal error)




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

error on start: initializing DST: no engine (v9.7.0-P2)

[Greg Whynott]

sorry,  forgot the subject.  not very good on my first posting

Hello,

I'm seeing an unfamiliar error while attempting to start a newly built from 
source named instance.   I've search on the net and within the bind-user list 
without luck,  DST returns lots of hits,  but nothing with "named DST". 
hoping someone here might know what its about.  Is it really a Day Light 
related?
thanks much for your time,
greg




the error:

[r...@fido ~]# /etc/init.d/named start
Starting named:[FAILED]
[r...@fido ~]# grep named /var/log/messages
Jun 13 10:20:00 fido named[2430]: starting BIND 9.7.0-P2 -u named
Jun 13 10:20:00 fido named[2430]: built with '--build=i386-redhat-linux-gnu' 
'--host=i386-redhat-linux-gnu' '--program-prefix=' 
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' 
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' 
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' 
'--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' 
'--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' 
'--disable-static' '--disable-openssl-version-check' 
'--with-pkcs11=/usr/lib/pkcs11/PKCS11_API.so' '--with-dlz-filesystem=yes' 
'--with-gssapi=yes' '--disable-isc-spnego' 'build_alias=i386-redhat-linux-gnu' 
'host_alias=i386-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables' 'CPPFLAGS= -DDIG_SIGCHASE'
Jun 13 10:20:00 fido named[2430]: adjusted limit on open files from 1024 to 
1048576
Jun 13 10:20:00 fido named[2430]: found 2 CPUs, using 2 worker threads
Jun 13 10:20:00 fido named[2430]: using up to 4096 sockets

Jun 13 10:20:00 fido named[2430]: initializing DST: no engine
Jun 13 10:20:00 fido named[2430]: exiting (due to fatal error)




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

Re: error on start: initializing DST: no engine (v9.7.0-P2)

[Greg Whynott]

Hi Cathy and thanks for the reply.

I stole the options from what the previous binary being replaced was built 
with.  Its a redhat system,  thought I'd try and keep things the same as much 
as possible.   Later on that day I stripped the options down to just path 
preferences and a few others,  the error went away.  

thanks again and have a great day,
greg



On Jun 14, 2010, at 6:25 AM, Cathy Almond wrote:

> Greg Whynott wrote:
>> sorry,  forgot the subject.  not very good on my first posting
>> 
>> Hello,
>> 
>> I'm seeing an unfamiliar error while attempting to start a newly built from 
>> source named instance.   I've search on the net and within the bind-user 
>> list without luck,  DST returns lots of hits,  but nothing with "named DST". 
>> hoping someone here might know what its about.  Is it really a Day Light 
>> related?
>> thanks much for your time,
>> greg
>> 
>> 
>> 
>> 
>> the error:
>> 
>> [r...@fido ~]# /etc/init.d/named start
>> Starting named:[FAILED]
>> [r...@fido ~]# grep named /var/log/messages
>> Jun 13 10:20:00 fido named[2430]: starting BIND 9.7.0-P2 -u named
>> Jun 13 10:20:00 fido named[2430]: built with '--build=i386-redhat-linux-gnu' 
>> '--host=i386-redhat-linux-gnu' '--program-prefix=' 
>> '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' 
>> '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' 
>> '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' 
>> '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' 
>> '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' 
>> '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' 
>> '--disable-static' '--disable-openssl-version-check' 
>> '--with-pkcs11=/usr/lib/pkcs11/PKCS11_API.so' '--with-dlz-filesystem=yes' 
>> '--with-gssapi=yes' '--disable-isc-spnego' 
>> 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 
>> 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
>> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
>> -fasynchronous-unwind-tables' 'CPPFLAGS= -DDIG_SIGCHASE'
>> Jun 13 10:20:00 fido named[2430]: adjusted limit on open files from 1024 to 
>> 1048576
>> Jun 13 10:20:00 fido named[2430]: found 2 CPUs, using 2 worker threads
>> Jun 13 10:20:00 fido named[2430]: using up to 4096 sockets
>> 
>> Jun 13 10:20:00 fido named[2430]: initializing DST: no engine
>> Jun 13 10:20:00 fido named[2430]: exiting (due to fatal error)
>> 
> 
> No - not "daylight saving time" :-)
> 
> It's the Digital Signature Toolkit subsystem (it interfaces between BIND
> and the cryptography it uses).
> 
> The error is reported during from ~/bin/named/server.c during the
> initialization/startup phase because an error is returned from the call
> to dst_lib_init2().  This function initializes the DST subsystem - you
> can find it in ~/lib/dns/dst_api.c.  What api calls it makes depends on
> what options named was built with.
> 
> Looking at the long list of options passed to configure I would first
> hazard a guess that something is missing from your environment that
> named is expecting because of how it has been built.  Are these all
> configure options that you selected manually?  For example,
> "--with-pkcs11=..." is one likely candidate to cause problems if you're
> not going to be using a PKCS#11 interface to a hardware module.  A good
> rule with configure is always to use the defaults except where you
> definitely know why you need something different.
> 
> Hope this helps.
> 
> Cathy
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

Re: My ISP's private address space has dns entries available on the public net , is this right ?

[Greg Whynott]

I'd say no,  and your ISP may need to gain a working knowledge of bind views if 
they need to resolve 1812 addresses for their own needs without affecting 
customers who are using the ISP DNS servers as their resolver.

the way you could fix this without their involvement is to bring up your own 
DNS server which is master for the zone you are using internally.  any queries 
it can't answer,  will only then be forwarded off to your ISP.


-g


On Aug 9, 2010, at 8:09 PM, donovan jeffrey j wrote:

> Greetings
> 
> my isp has some private address space which has dns resolution and can be 
> queried from the outside world.
> 
> I asked them about this because we use this private address space and it is 
> showing up in our DNS lookups. here was there response;
> 
>>   I've discussed this with our systems administrators and have been told 
>> that this is performing as expected.  ISP DNS servers do contain information 
>> about private adresses that are in use on our network.  If you are utilizing 
>> our DNS servers, you will see resolution of private IPs to ISP hostnames 
>> when appropriate.  That will not occur using external DNS servers.  You will 
>> see resolution of PTD hostnames to private IPs from external servers, but 
>> not IP resolution to hostnames.  As long as reverse DNS (IP to hostname) is 
>> not propogating, things are functioning normally.
> 
> so even from google public dns i see lookups that refer back to a private 
> address space on my ISP's net.
> 
> is that right ?
> -j
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

Re: My ISP's private address space has dns entries available on the public net , is this right ?

[Greg Whynott]

sorry,  1918,  not 1812…  



On Aug 10, 2010, at 10:43 AM, Greg Whynott wrote:

> I'd say no,  and your ISP may need to gain a working knowledge of bind views 
> if they need to resolve 1812 addresses for their own needs without affecting 
> customers who are using the ISP DNS servers as their resolver.
> 
> the way you could fix this without their involvement is to bring up your own 
> DNS server which is master for the zone you are using internally.  any 
> queries it can't answer,  will only then be forwarded off to your ISP.
> 
> 
> -g
> 
> 
> On Aug 9, 2010, at 8:09 PM, donovan jeffrey j wrote:
> 
>> Greetings
>> 
>> my isp has some private address space which has dns resolution and can be 
>> queried from the outside world.
>> 
>> I asked them about this because we use this private address space and it is 
>> showing up in our DNS lookups. here was there response;
>> 
>>>  I've discussed this with our systems administrators and have been told 
>>> that this is performing as expected.  ISP DNS servers do contain 
>>> information about private adresses that are in use on our network.  If you 
>>> are utilizing our DNS servers, you will see resolution of private IPs to 
>>> ISP hostnames when appropriate.  That will not occur using external DNS 
>>> servers.  You will see resolution of PTD hostnames to private IPs from 
>>> external servers, but not IP resolution to hostnames.  As long as reverse 
>>> DNS (IP to hostname) is not propogating, things are functioning normally.
>> 
>> so even from google public dns i see lookups that refer back to a private 
>> address space on my ISP's net.
>> 
>> is that right ?
>> -j
>> ___
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 

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

filter packets bound for company proxy server?

[Greg Hauptmann]

Hi,

Can I ask if anyone has a good idea for how I could identify (filter
packets) that are transiting via a company proxy server [e.g.
proxy.mycompany.com].   The challenge here is that the DNS server will
issue any one of a number of IP addresses back to the browser to use,
associated with the range of physical separate proxy servers that you
might end up on.

I've tried using the filter "host <>" however this
doesn't seem to work.  In fact some testing I did with wireshark to
provide an example of what I'm seeing is:

ASSUMPTIONS:  First in terms of some assumptions for the sake of this example:

 nslookup proxy.mycompany.com
 Name:proxy.xxx..yyy.mycompany.com
 Address:  10.10.1.10
 Aliases:  proxy.mycompany.com

 nslookup 10.1.1.10
 Name:proxy3.zzz.aaa.mycompany.com
 Address:  10.10.1.10

WIRESHARK RESULTS FOR GIVEN CAPTURE FILTER:

 a) "host proxy.mycompany.com" => Does not pickup the browser traffic
I created that transits the proxy.  Again my goal is to find a way to
filter on this.

 b) "host proxy3.zzz.aaa.mycompany.com" => Does pick up the traffic
BUT of course I've had to manually type in the actual proxy server. I
tested with the same browser straight after putting in the capture
filter so the proxy I was handed back obviously didn't change in that
small time (i.e. at other time I would be handed off to
proxy5.zzz.aaa.mycompany.com say for example)


So I'm running out of ideas re how I could identify whether, for a
given packet, whether it is one that has transited via the proxy
serverany ideas?

Would "dig" be a reliable way to get a list of all IP's associated
with the main proxy DNS name? Would this be a possible solution re
identifying them all perhaps?

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

Re: Resolving RFC1918 addresses on recursive, caching servers

[Greg Rivers]

On Friday, November 10, 2017 10:27:53 Mark Andrews wrote:
> Just slave the zones on the recursive servers.   When you forward that server 
> does
> all the recursion and returns the answer to you.  If you do use forwarding 
> for RFC 1918
> zones use “forward only;” as you really don’t want talk to the AS112 servers.
> 
> RFC 1918 reverse support really is easy.  You slave the zones at the top of 
> the
> part of the name space you are using (10.in-addr.arpa, 16.172.in-addr.arpa …
> 31.172.in-addr.arpa, 168.192.in-addr.arpa) and follow delegations from them to
> deeper zones.
>
Stub zones work well for that too, e.g.:

// Referrals to our RFC 1918 masters.
zone "10.in-addr.arpa" { type stub; file "/etc/namedb/slave/10.db"; masters { 
xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "16.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.16.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "17.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.17.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "18.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.18.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "19.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.19.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "20.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.20.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "21.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.21.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "22.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.22.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "23.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.23.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "24.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.24.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "25.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.25.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "26.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.26.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "27.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.27.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "28.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.28.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "29.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.29.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "30.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.30.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "31.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.31.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "168.192.in-addr.arpa" { type stub; file "/etc/namedb/slave/192.168.db"; 
masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };

With stub zones, you only slave the NS records, not the whole zones.

> People over use forward zones.
>
I've found that to be the case as well.

-- 
Greg Rivers
___
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: root hints

[Greg Rivers]

On Wednesday, May 02, 2018 16:48:00 Rick Dicaire wrote:
> ... what is the official/best practise/recommended way to update root.hints?
>
https://www.iana.org/domains/root/files

But you don't really need it unless you're running an internal root; as stated 
at that link, "For many pieces of software, this list comes built into the 
software.". As I recall, this is true for BIND.

-- 
Greg Rivers
___
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: Timeout and SERVFAIL

[Greg Rivers]

On Tuesday, May 29, 2018 16:53:02 Alex wrote:
> ...
> 
> Last week the network with the master and one of the slaves went down
> for an extended period. Requests appeared to still be served by the
> second slave on the totally different network.
> 
> At least for a while. It appeared once the negative cache expired
> after 24h, requests to the domain just resulted in SERVFAIL.
> 
> @  INSOA   ns.example.com. admin.ns.example.com. (
> 2018041703  ;serial (mmddxx)
> 3h  ;refresh every 3 hr
> 1h  ;retry every 1 hr
> 7d  ;expire in 7 days
> 1d );negative cache minimum ttl 1 day
> 
> How can I configure the name servers so failure of one or two doesn't
> impact the third?
> 
Unless it is also serving recursive queries, caching is not a factor on an 
authoritative server. What expired was not the negative cache interval; it was 
the zone expiration interval. To avoid the possibility of returning incorrect 
information, a secondary server stops serving a zone when the zone expiration 
period passes without contact with its master(s). This is by design.

To remedy this, you must ensure that the above condition does not occur. You 
must either get your master(s) back online faster, or increase the zone 
expiration period in your SOAs, or both.

> In the time leading up to the cache expiring, were other requests
> being rejected due to the two nameservers for that zone being
> unreachable?
>
No. You should find the zone expiration event in your logs.

-- 
Greg Rivers
___
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: Authoritative dns with private IP for hostname

[Greg Rivers]

On Friday, July 27, 2018 12:59:42 Elias Pereira wrote:
> Can an authoritative dns for a domain, eg mydomain.tdl, have a hostname,
> example, wordpress.mydomain.tdl with a private IP?
> 
Yes, but that won't be useful outside of your LAN.

> Would this be accessible from the internet via hostname, if I did a nat on
> the firewall?
>
No, by definition, private addresses are not routable on the Internet.

-- 
Greg Rivers
___
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: Authoritative dns with private IP for hostname

[Greg Rivers]

In summary, all of the advice you received on this thread regarding the 
publishing of private IPs in DNS is correct:

• As I told you, on a purely practical level, it won't work because private 
addresses aren't routable on the Internet.

• As Kevin told you, there are myriad security ramifications, as everyone and 
no one controls routing of private addresses locally.

• As Timothe told you, views can be used effectively, though as things scale 
up, your ability to use views will hinge on your ability to manage them.

To provide service to the Internet, you need a public IP. It may be that we 
misunderstood the wording of your question. If your actual question was "can I 
publish a public IP in DNS and NAT it to a private IP behind my firewall", then 
of course the answer is "yes". Otherwise, trust the given advice.

-- 
Greg Rivers
___
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: named tcp dos?

[Greg Rivers]

On Thursday, August 02, 2018 12:58:32 Randy Bush wrote:
> ... are there that many folk doing tcp out there?
> 
All name servers fall back to TCP when they receive truncated replies.

-- 
Greg Rivers
___
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: named tcp dos?

[Greg Rivers]

On Thursday, August 02, 2018 22:12:38 Reindl Harald wrote:
> 
> Am 02.08.2018 um 22:07 schrieb Randy Bush:
> >>> ... are there that many folk doing tcp out there?
> >> All name servers fall back to TCP when they receive truncated replies.
> > 
> > we know the protocol.  [ and we know folk have idiot middleboxen ]
> > 
> > what i was asking was the distribution of this in the wild
> 
> one word: DNSSEC
>
Indeed, DNSSEC is a prime example. My point was that TCP queries to your 
servers are determined largely by the size of the RRSETs you serve. If your 
answers don't fit in 512 bytes (without EDNS) or ~4096 bytes (with EDNS), 
you're going to be serving over TCP. Obviously you're way more likely to see 
TCP queries from systems that don't support EDNS. Perhaps you have many such 
systems (and or idiot middleboxen) querying you?

-- 
Greg
___
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: named tcp dos?

[Greg Rivers]

On Thursday, August 02, 2018 18:13:21 Randy Bush wrote:
> > We run about 300 TLD's on our DNS platform and get roughly 5-10% TCP
> > queries.
> 
> that is quite a variance
> 
> > In comparison, we get about 25-30% IPv6 queries.
> 
> wonder how that compares to others
> 
On the secondaries for a Fortune 50 company with a sizeable ecommerce presence, 
we see ~17% of queries come in over IPv6, and ~2.5% are TCP queries. With 
respect to the Internet, the v6 percentage is probably low, as the servers I 
checked answer quite a lot of queries from internal IPv4 networks.

For grins, I turned on query logging on one server (BIND 9.11.4) for a short 
time and produced a histogram of the unique query attribute combinations:

$ awk '"query:"==$10 {print $(NF-1)}' /var/log/daemon.2 | sort | uniq -c | sort 
-rn | tee >(awk '{s+=$1}END{print s}')
38111265 -E(0)DC
4963452 -E(0)D
4784394 -
3268810 -E(0)
896136 +E(0)DC
551934 -E(0)TDC
406856 -E(0)DCV
318068 -E(0)DV
282536 -E(0)DCK
173078 -T
149780 -E(0)TD
132303 -E(0)DK
107240 -C
105752 -E(0)T
32748 -E(0)TDV
24677 +
21722 -E(0)TDCV
10958 -E(0)C
10907 +T
 337 -E(0)TDCK
 174 +E(0)
 135 -TC
 131 -E(0)TDK
  98 +E(0)TDC
  19 +E(0)D
  18 +E(0)K
   8 -E(0)TC
   3 +E(0)T
54353539

FWIW, this indicates that most TCP queries come from clients that claim to 
support EDNS0.

-- 
Greg Rivers
___
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: how two dns bind master sync?

[Greg Rivers]

On Wednesday, August 22, 2018 11:42:35 Grant Taylor via bind-users wrote:
> On 08/22/2018 01:15 AM, Zhengyu Pan wrote:
> > In my application scenario, I have two master. Each master connect 
> > several slave dns. When users update zone, i update these two master 
> > respectively in a for loop. However, when any master update fails, i 
> > will roll bock. you know, whenever any update, zone's serial will 
> > increase. this cause that the serial numbers of zone in two masters are 
> > inconsistent. How can i keep these two masters' zones consistent in real 
> > time? Is using rsync tool a good way?  In the industry, is there a good 
> > way to synchronize two masters?
> 
> This may be an unpopular opinion, especially on the BIND-Users mailing 
> list (sometimes BIND is not the best answer).
> 
> It sounds like you might want something like multi-master DNS servers 
> that Active Directory (with AD integrated zones) provides.
> 
> You can "Enable BIND secondaries" to allow (any) slave server to do a 
> standard zone transfer.
> 
> You could then make your change to one master DNS server and AD will 
> ensure that the other gets it too.  Either way, without reconfiguring 
> anything.
> 
> I would love to see this type of feature in BIND.  But I've not seen
> anything provide it yet.
> 
Other possibilities exist too. For example, the Men & Mice DDI product[1] 
supports multi-master across multiple disparate primaries with their "xDNS" 
plugin. But I wouldn't say that multi-master is a good idea in general, as it 
suffers from all of the problems that come with having multiple versions of the 
truth.

[1] <https://www.menandmice.com/products/dns-management/>

-- 
Greg Rivers
___
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: isc-bind-esv Repository - "yum update" doing undesirable things!

[Greg Rivers]

On Wednesday, May 8, 2019 1:49:38 PM CDT Matthew Richardson wrote:
> I have been using the isc-bind-esv repository on Centos 7 since it was
> created.  On each upgrade, a "yum update" has done the correct thing by
> upgrading from the running version to the latest version.
> 
> Today (happily on a cloned test server!) I repeated this with the upgrade
> being from 9.11.6 to 9.11.6.P1-1.2.el7.
> 
> It seems that the package names have changed and that Bind is now installed
> in a new directory structure below /opt/isc.  In my case, a previously
> working authoratitive configuration is now comprehensively broken.
> 
> Before troubleshooting, I was wondering whether I had missed any release
> notes or similar which might explain what is going on.
> 
Probably ISC's new packages have installed a "Software Collection" to avoid 
conflicts with "native" packages. Read the scl(1) manual page for more 
information. To get a shell with the proper context to manage named, you'll 
need to run something like `scl enable isc-bind bash`. Or to run ad hoc 
commands, `scl enable isc-bind -- named -V`, etc.. And as you noticed, named's 
configuration and data are now under /opt/isc/isc-bind/.

-- 
Greg


___
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: Logging of notify sending

[Greg Rivers]

On Saturday, May 25, 2019 4:07:45 PM CDT Axel Rau wrote:
> > Am 25.05.2019 um 22:30 schrieb Anand Buddhdev :
> > 25-May-2019 10:00:02.589 notify: zone 2.in-addr.arpa/IN: sending notifies
> > (serial 1558778402)
>
> Yes, but even with debug 8, I get only this summary.
> No chance to get an log entry per server and the TSIG key in use.
>
As Rick Dicaire said previously, "Notifications themselves don't use TSIG". You 
will never see a TSIG key associated with a notify because notifies aren't 
signed; the zone transfers triggered by notifies are.

-- 
Greg Rivers


___
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: Logging of notify sending

[Greg Rivers]

On Sunday, May 26, 2019 11:51:38 AM CDT Axel Rau wrote:
> 
> > Am 26.05.2019 um 18:38 schrieb Rick Dicaire :
> 
> > A quick google search of "bind also-notify key" returns:
> > 
> > https://kb.isc.org/docs/aa-00851
> > https://kb.isc.org/docs/aa-00296
> > 
> > Looks like keys provide a means to differentiate views.
> 
> ARM for bind 9.14.1 says on page 24:
> 
> For example, a key may be specified for each server in the masters statement 
> in
> the definition of a slave zone; in this case, all SOA QUERY messages, NOTIFY
> messages, and zone transfer requests (AXFR or IXFR) will be signed using the
> specified key. Keys may also be specified in the also-notify statement of a
> master or slave zone, causing NOTIFY messages to be signed using the specified
> key.
> 
So it does. Seems my knowledge of this was either outdated or just plain wrong. 
Thanks for pointing this out.

-- 
Greg


___
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, OpenDNS and www.cdc.gov

[Greg Choules]

Hi Bob.
See if this article helps any first, before we get into configs: 
https://kb.isc.org/docs/the-umbrella-feature-in-detail

Cheers, Greg

> On 16 Oct 2024, at 14:55, Robert Mankowski  
> wrote:
> 
> I recently implemented a forward only BIND server for home. I was forwarding 
> to OpenDNS FamilyShield using TLS and DNSSEC at first, but I was getting a 
> noticeable amount of SERVFAIL responses. I believe it is related to DNSSEC 
> (see delv tests below), but I don’t believe it is my configuration because 
> when I forward to Cloudflare’s Family service, or to Google DNS, I don’t have 
> any problems with the same domains (e.g. www.cdc.gov <http://www.cdc.gov/>).
>  
> I contacted Cisco Umbrella support because I was thinking it’s an issue with 
> their servers, but they didn’t really help, so I thought I would try this 
> list for advice.
>  
> Would appreciate it if someone could review my configuration and/or reproduce 
> my results to see if I’m doing something wrong.
>  
> Thanks,
>  
> Bob
>  
> Here are some tests I ran:
>  
> admin@router1:~$ apt-cache policy bind9
> bind9:
>   Installed: 1:9.21.1-1+0~20240920.124+debian12~1.gbp62e0e7
>   Candidate: 1:9.21.1-1+0~20240920.124+debian12~1.gbp62e0e7
>   Version table:
> *** 1:9.21.1-1+0~20240920.124+debian12~1.gbp62e0e7 500
> 500 https://packages.sury.org/bind-dev bookworm/main amd64 Packages
> 100 /var/lib/dpkg/status
>  1:9.18.28-1~deb12u2 500
> 500 http://deb.debian.org/debian bookworm/main amd64 Packages
> 500 http://security.debian.org/debian-security bookworm-security/main 
> amd64 Packages
>  
>  
> admin@router1:~$ delv -v
> delv 9.21.1-1+0~20240920.124+debian12~1.gbp62e0e7-Debian
>  
> admin@router1:~$ delv -4 @208.67.220.123 www.cdc.gov <http://www.cdc.gov/>. A
> ;; insecurity proof failed resolving 'cdc.gov/DNSKEY/IN': 
> <http://cdc.gov/DNSKEY/IN':> 208.67.220.123#53
> ;; broken trust chain resolving 'www.cdc.gov/A/IN': 
> <http://www.cdc.gov/A/IN':> 208.67.220.123#53
> ;; resolution failed: broken trust chain
>  
> admin@router1:~$ delv -4 @208.67.222.123 www.cdc.gov <http://www.cdc.gov/>. A
> ;; insecurity proof failed resolving 'cdc.gov/DNSKEY/IN': 
> <http://cdc.gov/DNSKEY/IN':> 208.67.222.123#53
> ;; broken trust chain resolving 'www.cdc.gov/A/IN': 
> <http://www.cdc.gov/A/IN':> 208.67.222.123#53
> ;; resolution failed: broken trust chain
>  
> admin@router1:~$ delv -4 @1.1.1.3 www.cdc.gov <http://www.cdc.gov/>. A
> ; fully validated
> www.cdc.gov <http://www.cdc.gov/>.248 IN  CNAME   
> www.akam.cdc.gov <http://www.akam.cdc.gov/>.
> www.cdc.gov <http://www.cdc.gov/>.248 IN  RRSIG   CNAME 8 
> 3 300 20241019153420 20241009150230 1503 cdc.gov <http://cdc.gov/>. 
> b99UIGmCOTJj+C7JFXORmtUXQEIIGdF0q3Z5u6HfAbKcJhjfFjJrkRE6 
> yntzr0pSksCp1Uwi146xvKz7ImCqkYK67/WlOujyquOGSfgOwO1DvUyj 
> TfvXJWvjSRLTx30lwU6RV80RrC596A16anTpLc7Zi4VEAVncRHeUl1y1 
> /MG/CSCtE/Ef6tPD1FtGZjhXszVAgrk3fhISCsImRHuGAoIBnIKCKx2M 
> YMhxirfV0z9Qq46PnW9zTzh+EbVKZkN0C+Xl3j2+4sqyHlubhrtgklG/ 
> g0u+99/g/jdfex+Vh7dtcAXFcTZ1XGuPQXgsn6GrznecB8PaXmCxXfft GaDOdQ==
> www.akam.cdc.gov <http://www.akam.cdc.gov/>.   20  IN  A   
> 23.51.224.222
> www.akam.cdc.gov <http://www.akam.cdc.gov/>.   20  IN  RRSIG   A 
> 10 4 20 20241018102927 20241015092927 16701 akam.cdc.gov 
> <http://akam.cdc.gov/>. 
> Lcd7WthqqU+A7UwQkBHZsT0nqxztJkn9cx57wXr4eHHCvJR0cCxZFkwl 
> eIbSffPIu364terXJlcEvuWbWTLrCX7bo0c6B9bA5EPi2DsbegTfkG5u 
> cqrZP9RTzXbfbs5l5w6CQ9DfSPcYx9BIYkusErQu5qQnGhoQ5bXI1VxT Otc=
>  
> The relevant portion of my named configuration is:
>  
> tls opendns-tls {
> remote-hostname "dns.opendns.com <http://dns.opendns.com/>";
> };
>  
> tls cloudflare_family-tls {
> remote-hostname "one.one.one.one";
> };
>  
> tls google-tls {
> };
>  
> tls router1-tls {
> key-file "/var/cache/bind/privkey.pem";
> cert-file "/var/cache/bind/fullchain.pem";
> dhparam-file "/var/cache/bind/dhparam.pem";
> ciphers 
> "HIGH:!kRSA:!aNULL:!eNULL:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!SHA1:!SHA256:!SHA384";
> prefer-server-ciphers yes;
> session-tickets no;
> };
>  
> options {
> directory "/var/cache/bind";
> recursion yes;
> allow-query { trusted_nets; };
> version "none";
>  
> forwarders {
> #1.1.1.3 port 853 tls cloudflare_family-tls;
> #1.0.0.3 port 853 tls cloudf

Re: Question about recursive client max quota

[Greg Choules]

Hello Pedro.
Firstly, which version of BIND are you running?
Generally, though, increasing `recursive-clients` on a box with a decent amount 
of power and RAM is not an issue: 50k, or even bigger, should be fine. But 
please test it first. We have discussed raising the default but we’re not quite 
ready to make that change in a major release just yet.

Be aware, though, that if the resolver can’t get answers, it will probably 
SERVFAIL clients and the larger the backlog of clients the longer it will take 
to get around to responding to them, by which time they are likely to have 
timed out and be retrying anyway.

I hope that helps.
Greg

> On 8 Nov 2024, at 10:20, Pedro García Segura  wrote:
> 
> Hello,
> 
> Recently we had a Internet outage that lasted for a few hours and quickly 
> filled the recursive clients quota (set at 1000) since most internet-bound 
> recursive queries timed out, and our network is huge.
> 
> This also affected recursive queries to internal authoritative domains, thus 
> interrupting access to critical internal resources which don't have any 
> Internet/SaaS dependencies.
> 
> I'm having a hard time understanding the default recursive max quota being 
> set at 100 by default, since most modern servers now have RAM to spare, and 
> it's a bit scary to think that another Internet outage may happen again and 
> internal critical services may not be able to resolve internal authoritative 
> zones.
> 
> Can anyone give some insight into this issue? Can I just configure a huge 
> number of maximum recursive clientes (say 50k) to "absorb" the intetnet-bound 
> queries that are timing out and be able to respond to client requests for 
> internal authoritative zones?
> 
> I'm probably missing something, so thanks a lot for your understanding!
> 
> Cheers!
> Pedro
> -- 
> 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: How to print details of dns_name_t* when hitting a gdb breakpoint in dns_name_equal

[Greg Choules]

Hi Kees.
I would upgrade to 9.18 and not spend time trying to diagnose 9.16, which is 
not supported anymore. If the same problem occurs on 9.18 (latest), please let 
us know.

I hope that helps.
Greg

> On 3 Dec 2024, at 10:36, Kees Bakker via bind-users 
>  wrote:
> 
> Hi,
> 
> Background
> I have a CentOS FreeIPA setup with with multiple named (bind9 9.16.23) 
> servers.
> On two of my five servers, when I start named it fails a REQUIRE in 
> dns_name_equal
> 
> /*
>  * Either name1 is absolute and name2 is absolute, or neither is.
>  */
> REQUIRE((name1->attributes & DNS_NAMEATTR_ABSOLUTE) ==
> (name2->attributes & DNS_NAMEATTR_ABSOLUTE));
> 
> My question: if I run gdb and break in "assertion_failed", then "go up",
> how can I print name1 and name2 in a meaningful manner,
> so that I can figure out what entries are causing this failure?
> 
> Just doing "p *name1" in gdb isn't very helpful for that.
> 
> BTW My work around is to keep restarting named until it no longer fails
> on that REQUIRE.
> 
> Any help is greatly appreciated.
> -- Kees
> -- 
> 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: localhost name lookup

[Greg Choules]

> On 24 Jan 2025, at 19:07, Lee  wrote:
> 
> On Mon, Jan 20, 2025 at 4:55 AM Petr Špaček wrote:
>> 
>> On 15. 01. 25 19:55, Lee wrote:
>>> On Wed, Jan 15, 2025 at 11:55 AM Ondřej Surý wrote:
 On 14. 1. 2025, at 16:56, Lee  wrote:
 
 In other words, should I submit a bug report to the Debian bind
 maintainers or ISC?
 
 
 With both my ISC and Debian hats on, I am going to be very frank
 and say this has a very low priority, so unless you actually want to
 work on this and submit a solid correct patch with a good reasoning,
 there's probably nobody that is going to work on this.
>>> 
>>> I appreciate the honesty, but I think I'm missing something?
>>> 
>>> The good reasoning part would be quoting the RFC and the solid correct
>>> patch would be stripping out everything except the two line change I
>>> made to my db.local in the original post.
>> 
>> Unfortunately not quite, BIND does not ship with any zone files.
> 
> Really?!  I installed BIND on windows however long ago when it was
> supported on Windows and it came with a db.local that looked identical
> to the one that came with Debian.

Certainly for the last quite a lot of years there hasn't been a hint zone file 
- whatever it might be called - shipped with BIND, if ever: there are too many 
releases to search through.
The current (at the time of release) set of root servers are contained in the 
file rootns.c, but this is definitely not a zone file, just the place BIND gets 
its built-in hints from.
I would think that, if a file called db.local, db.hint, db.root or whatever 
does exist, it is someone else who created it.

> 
>> It
>> would have to be code change to implement
>> https://datatracker.ietf.org/doc/html/rfc6761#section-6.3
>> inside BIND codebase, something similar to empty zones.
>> 
>> (Or, refactor codebase to pull all special zones from files, which is
>> ... well ... somewhat larger change.)
>> 
>> Perhaps in packages it would be easier (albeit limited impact), but I
>> don't maintain any of them myself.
>> 
>>> Is anything else required other than formatting the [implicit] change
>>> as a patch?
>>> 
 The itch to scratch here isn't particularly bothering.
>>> 
>>> I understand.  Where do I submit the patch?
>> 
>> Please start with
>> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/CONTRIBUTING.md
> 
> With db.local not being in the ISC code base it seems like I should be
> submitting the bug report to Debian.
> But with Ondřej Surý saying
 With both my ISC and Debian hats on
> 
> approval seems unlikely.
> 
> I appreciate all your help but I've taken up enough of everyone's
> time; I'll quit now.
> 
> Thanks,
> Lee
> -- 
> 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: localhost name lookup

[Greg Choules]

> On 24 Jan 2025, at 21:32, Lee  wrote:
> 
> On Fri, Jan 24, 2025 at 3:27 PM Greg Choules wrote:
>> 
>> 
>>> On 24 Jan 2025, at 19:07, Lee  wrote:
>>> 
>>> On Mon, Jan 20, 2025 at 4:55 AM Petr Špaček wrote:
>>>> 
>>>> On 15. 01. 25 19:55, Lee wrote:
>>>>> On Wed, Jan 15, 2025 at 11:55 AM Ondřej Surý wrote:
>>>>>> On 14. 1. 2025, at 16:56, Lee  wrote:
>>>>>> 
>>>>>> In other words, should I submit a bug report to the Debian bind
>>>>>> maintainers or ISC?
>>>>>> 
>>>>>> 
>>>>>> With both my ISC and Debian hats on, I am going to be very frank
>>>>>> and say this has a very low priority, so unless you actually want to
>>>>>> work on this and submit a solid correct patch with a good reasoning,
>>>>>> there's probably nobody that is going to work on this.
>>>>> 
>>>>> I appreciate the honesty, but I think I'm missing something?
>>>>> 
>>>>> The good reasoning part would be quoting the RFC and the solid correct
>>>>> patch would be stripping out everything except the two line change I
>>>>> made to my db.local in the original post.
>>>> 
>>>> Unfortunately not quite, BIND does not ship with any zone files.
>>> 
>>> Really?!  I installed BIND on windows however long ago when it was
>>> supported on Windows and it came with a db.local that looked identical
>>> to the one that came with Debian.
>> 
>> Certainly for the last quite a lot of years there hasn't been a hint zone 
>> file - whatever it might be called - shipped with BIND, if ever: there are 
>> too many releases to search through.
>> The current (at the time of release) set of root servers are contained in 
>> the file rootns.c, but this is definitely not a zone file, just the place 
>> BIND gets its built-in hints from.
>> I would think that, if a file called db.local, db.hint, db.root or whatever 
>> does exist, it is someone else who created it.
> 
> I don't know who created or included db.local in the distribution of
> bind.  What I do know is that my installation of bind on windows and
> my installation of bind on debian came with a db.local -- here's the
> one that came with my installation of bind on Windows:
> 

I just looked in the source for 9.0.0, released nearly 25 years ago, to see 
what was there because I was curious. There is no file called “db.local": 
here’s the link if you want to check for yourself: 
https://downloads.isc.org/isc/bind9/9.0.0/ Every release since then is also 
available to download, should you want to check them all.
So the fact that you *do* have a file called “db.local", I think means nothing. 
Anyone could have created that for some purpose only they knew at the time.

> C:\MyProgs\BIND\etc>more db.local
> ;
> ; BIND data file for local loopback interface
> ;
> $TTL604800
> @   IN  SOA localhost. root.localhost. (
>  2 ; Serial
> 604800 ; Refresh
>  86400 ; Retry
>2419200 ; Expire
> 604800 )   ; Negative Cache TTL
> ;
> @   IN  NS  localhost.
> @   IN  A   127.0.0.1
> @   IN  ::1
> 
> C:\MyProgs\BIND\etc>
> 
> and here's my modified copy of db.local on my Debian machine (I added
> the two wildcard lines for .localhost.)
> 
> lee@spot /etc/bind
> $ cat db.local
> ;
> ; BIND data file for local loopback interface
> ;
> $TTL604800
> @   IN  SOA localhost. root.localhost. (
>  3 ; Serial
> 604800 ; Refresh
>  86400 ; Retry
>2419200 ; Expire
> 604800 )   ; Negative Cache TTL
> ;
> @   IN  NS  localhost.
> @   IN  A   127.0.0.1
> @   IN  ::1
> 
> *   IN  A   127.0.0.1
>IN  ::1
> 
> 
> lee@spot /etc/bind
> $ dig +short foo.bar.localhost 
> ::1
> 
> lee@spot /etc/bind
> $ grep db.local *
> named.conf.default-zones:   file "/etc/bind/db.local";
> 
> lee@spot /etc/bind
> $
> 
> 
> Regards,
> Lee

-- 
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 internal name space geo-proximity

[Greg Choules]

Hi Karol.
The DNS model is that if a zone contains multiple records of the same type with 
the same owner name - e.g. google.com/NS <http://google.com/NS> - then all 
answers are returned in a response to a query: this is known as an RRSET. In 
the case of NS records, all RRSETs from anywhere must be the same, apart from 
the order of records in the set, otherwise the view of the DNS hierarchy 
becomes inconsistent. This is described here: 
https://datatracker.ietf.org/doc/html/rfc1034#section-2.2

If you use the example you provided, an NS query for google.com currently get 
these four answers:

;; ANSWER SECTION:
google.com. 341515  IN  NS  ns1.google.com.
google.com. 341515  IN  NS  ns4.google.com.
google.com. 341515  IN  NS  ns3.google.com.
google.com. 341515  IN  NS  ns2.google.com.

Note that, depending on how the authoritative server providing those answers 
has been configured they may be listed in the same order each time or in a 
random order. So it is not reliable, nor correct anyway, to provide only one of 
these records based on who is querying.

One feature you might want to take a look at is BIND’s GeoIP support, described 
here: https://bind9.readthedocs.io/en/latest/chapter7.html#access-control-lists 
here: 
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-geoip-directory
  and here: https://kb.isc.org/docs/aa-00971 

I hope that helps.
Cheers, Greg

> On 21 Mar 2025, at 22:16, Karol Nowicki via bind-users 
>  wrote:
> 
> Hello Everyone 
> 
> Do we have any option to define order of domain delegation depends from query 
> location ? 
> 
> For example
> 
> google.com. NS  dns1.company.com.
> google.com. NS  dns2.company.com.
> 
> All in one zone file. 
> 
> Now when client’s query comes from north america then delegates only to dns1, 
> when query comes from Europe then delegates to dns2
> 
> 
> Wysłane z Yahoo Mail do iPhone 
> <https://mail.onelink.me/107872968?pid=nativeplacement&c=Global_Acquisition_YMktg_315_Internal_EmailSignature&af_sub1=Acquisition&af_sub2=Global_YMktg&af_sub3=&af_sub4=10604&af_sub5=EmailSignature__Static_>
> -- 
> 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: rndc: 'reload' failed: unexpected error

[Greg Choules]

Hi Duan.
Firstly, please upgrade to the latest BIND as 9.11 is very old now and has many 
security flaws that will not be fixed because it is obsolete.

Secondly, after you have upgraded try it again and if the problem still exists, 
come back here.

Cheers, Greg

> On 13 Mar 2025, at 09:23, Duan Duan via bind-users  
> wrote:
> 
> Hey Guys,
> 
> I am using bind version 9.11.0.
>  
> There are many views and zones running inside.
>  
> bind can run normally and resolve domain names normally.
>  
> But when I execute rndc reload, I I received an error message.
>  
> ./server.c:3799: unexpected error:
> unable to obtain neither an IPv4 nor an IPv6 dispatch
> reloading configuration failed: unexpected error
> 
> But when I execute named -n half core, there's no problem.
>  
> A lot of research, but I don't know why.
>  
> Thanks,
>  
> Kind regards
> Duan
> -- 
> 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: Views vs Separate Authoritative & Recursive DNS

[Greg Choules via bind-users]

Hi E R.
My short answer would be, don't configure views unless you have a good use
case for them. For example you are running resolvers that have two
different kinds of clients that need to be handled differently - one client
set needs RPZ, the other doesn't. Or something like that.

BIND has views inside anyway. If you run "rndc stats" it produces a file
called "named.stats", in which you will see line like this:
[View: _bind]
[View: default]
The "_bind" view is always there and is used for internal processing. The
"default" exists for all client processing and if you define your own views
it disappears. So having one user-defined view is functionally
equivalent to having no views.

One possible reason I can think of for defining a view would be if you know
you will need to add more views in future, so would like to standardise the
structure of your config day one. It's a bit like configuring an Ethernet
switch: do I configure VLANs even though (today) it's one flat network?

Hope that helps.
Greg

On Wed, 4 Jan 2023 at 01:15, E R  wrote:

> New to BIND and just starting to read the 5th edition from O'Reilly after
> watching some videos online while it made its way to me.  I am trying to
> understand why the view statement appears to be included by default in most
> Linux distributions if best practice says you should have separate servers
> for each?  Based on the comments in the named.conf sample file I am
> inclined to remove all of the view statements so it operates in "default
> view" on new servers I am setting up to replace old ones.  Is the view
> statement just there for those who need to ignore best practices or am I
> missing something?
> --
> 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: I need to find statistics on a running server.

[Greg Choules via bind-users]

Hi Jeff.
Query logging is quite an overhead and very heavy on writing to storage, so
use it sparingly as it can have a detrimental impact on performance. For
any moderately loaded server I would not have it enabled by default.

Cheers, Greg

On Thu, 12 Jan 2023 at 18:22, Jeff Sumner  wrote:

> I’ve turned on query logging, then grepped for the count of lines logged
> in a particular second.
>
>
>
> Worked well enough for the job at the time.
>
>
>
> J
>
>
>
> *De: *bind-users  em nome de "King,
> Harold Clyde (Hal) via bind-users" 
> *Responder A: *"King, Harold Clyde (Hal)" 
> *Data: *quinta-feira, 12 de janeiro de 2023 1:20 PM
> *Para: *bind-users 
> *Assunto: *I need to find statistics on a running server.
>
>
>
> I need to find some answers like queries per second.  Any fast ideas folks?
>
>
> --
>
> Hal King  - h...@utk.edu
> Systems Administrator
> Office of Information Technology
> Shared Services
>
> The University of Tennessee
> 103c5 Kingston Pike Building
> 2309 Kingston Pk. Knoxville, TN 37996
> Phone: 974-1599
>
> [image: cid:ddc53916-50a2-4e86-8dac-18eabfd73205]
>
> -- 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: Use UDP for (small) incremental zone transfers?

[Greg Choules via bind-users]

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

Cheers, Greg

On Fri, 13 Jan 2023 at 05:56, Jesus Cea  wrote:

> I have a dns zone with many dns updates per minute. The updates are
> tiny, like 2-3 records, <500 bytes in total.
>
> Currently my secondaries receive a NOTIFY and they do a TCP connection
> to request a incremental zone transfer. We know that TCP is "heavy" and
> the data I need to transfer is tiny before shutting down the TCP
> connection.
>
> Is there any way to do incremental zone transfer via UDP and, if the
> size is too big (>1232 bytes), fall back to TCP?
>
> Thanks!
>
> PS: I protect everything using TSIG.
>
> --
> Jesús Cea Avión _/_/  _/_/_/_/_/_/
> j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
> Twitter: @jcea_/_/_/_/  _/_/_/_/_/
> jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Use UDP for (small) incremental zone transfers?

[Greg Choules via bind-users]

Sending from the correct email alias!

Hi again.
How many is "many"? A busy server will be handling many 1000s of queries
per second. A few (tiny) zone transfers per minute will be background noise
compared to that and the extra overhead of TCP will be negligible
in comparison. IMHO it's not worth worrying about.

Cheers, Greg

On Fri, 13 Jan 2023 at 06:19, Jesus Cea  wrote:

> On 13/1/23 7:12, Greg Choules via bind-users wrote:
> > Hi Jesus.
> > No. Zone Transfer always uses TCP. Is it really that much of an overhead
> > for you?
>
> Not now, but it could be in the future, with many secondaries and many
> (tiny) updates per minute.
>
> Per your answer, I understand that zone transfers in current bind are
> TCP-only.
>
> Thanks.
>
> --
> Jesús Cea Avión _/_/  _/_/_/_/_/_/
> j...@jcea.es - https://www.jcea.es/_/_/_/_/  _/_/_/_/  _/_/
> Twitter: @jcea_/_/_/_/  _/_/_/_/_/
> jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
> "Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
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: SERVFAIL IPv6 debugging

[Greg Choules via bind-users]

Hi Bruce.
There's potentially a bunch of things to note here.
DNS conversations are independent of each other. The dig to your own server
(dig -6 ec.europa.eu) may be over v4 or v6. But the subsequent queries that
server makes (if any) may be over v4, or v6, or both. It depends how your
server is configured and what it's talking to.
DNSviz <https://dnsviz.net/d/europa.eu/dnssec/> is a handy tool for
visualizing what's happening in the delegation path down from the root to
your chosen domain and for europa.eu it highlights a couple of issues:
1) The NS RRSET in the child (europa.eu) is different to the NS RRSET in
the parent (eu)
2) One of the servers - 2001:978:2:1::93:2 - may have trouble with UDP
queries over v6. Having said that, from where I am I can make UDP queries
over v6 to it, both from dig and from my local BIND. However, it does
report a BADCOOKIE on the first attempt each time. For example:

dig @2001:978:2:1::93:2 europa.eu ds
;; BADCOOKIE, retrying.

; <<>> DiG 9.18.8 <<>> @2001:978:2:1::93:2 europa.eu ds
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21675
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6f81f2f4c5e1db7b7971793f63ca3c47a2566885353f2952 (good)
;; QUESTION SECTION:
;europa.eu. IN DS

;; ANSWER SECTION:
europa.eu. 86400 IN DS 14845 8 2
9EF3C28F5B3A3D33756D61715B1BDBDBB07E098D30256D1F2B71 95324846
europa.eu. 86400 IN DS 6250 8 2
0186EEFF28A83D2C950963CEEF2F2070DC0885AC8AD7106B03A9741C 25DC6B82

;; Query time: 21 msec
;; SERVER: 2001:978:2:1::93:2#53(2001:978:2:1::93:2) (UDP)
;; WHEN: Fri Jan 20 07:01:27 GMT 2023
;; MSG SIZE  rcvd: 162

So it *may* be that this server is the culprit. You will need to
gather more evidence though, to get a better idea. I would suggest that you
take a packet capture of all DNS traffic, flush the cache, then make digs @
your local server until you see the SERVFAIL and have fun in Wireshark.
If you can afford to put up with the noise, turn debugging up to the max -
rndc trace 99 - and see if anything pops out.
Also, when you say "even with dnssec turned off.." what do you mean,
exactly?

HTH
Greg

On Wed, 18 Jan 2023 at 12:32, Bruce Duncan  wrote:

> Hi bind-users,
>
> Apologies if this is inappropriate for this list. I am trying to debug a
> failure to resolve an external name.
>
> It appears that when I try to resolve the name ec.europa.eu over IPv6
> using either dig +trace or with a caching named that it sometimes fails:
>
> [nimbus]root: dig -6 ec.europa.eu
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> -6 ec.europa.eu
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29328
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ec.europa.eu.INA
>
> ;; Query time: 13 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Wed Jan 18 12:09:35 GMT 2023
> ;; MSG SIZE  rcvd: 41
>
> Sometimes I need to rndc flush and try again a few times before it
> fails. The named log says:
>
> 2023-01-18T12:09:35.145500+00:00 nimbus named[11833]: client
> @0x7f35e6fec700 ::1#35963 (ec.europa.eu): view internet: query failed
> (SERVFAIL) for ec.europa.eu/IN/A at ../../../bin/named/query.c:8580
>
> Various posts on the web suggest that query.c:8580 is related to dnssec
> validation, however even with dnssec turned off in /etc/named.conf the
> query still fails. I've tried setting rndc trace 9 but I get no more
> information about why the query has failed. Query logging is enabled but
> there is no information there either.
>
> I suspect there is some misconfiguration of the domain. dig -6 +trace
> sometimes complains that it can't find an address for some servers, but
> I don't understand why this would make the query fail completely sometimes.
>
> Any help appreciated!
>
> Thanks,
>
> Bruce
>
> --
> 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: recursion yes/no?

[Greg Choules via bind-users]

Hi David.
"recursion yes;" tells named that it can (if it has to) make queries to
other places if it needs more information in order to answer a client
query. Pure authoritative servers shouldn't need it and should have
"recursion no;". So the first question is, do your servers make queries out
to other places? If so, recursion must be enabled.
Secondly, do you have "minimal-responses" configured on either/both
servers? If so, what is it set to? There were changes in 9.16 so maybe
these explain your observations.

Cheers, Greg

On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users <
bind-users@lists.isc.org> wrote:

> Hello.
>
> I hope someone could help to understand the following.
>
> I have “my.domain.pt” and a master and slave server for the “my” part. I
> have been using “recursion yes” in both named.conf, as I want them to be
> both authoritative and cache for my clients.
>
> Last week I migrated my slave DNS server to version 9.16 and only today,
> after having issues with the primary server migration, I realized that for
> most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless
> I specify “+norec” with the dig command.
>
>
>
> My named.conf files only differ in IPs and “master/slave” setting.
>
>
>
> My questions:
>
> Should I use recursion on both? (Bear in mind that I also want them to
> provide chache to clients)
>
> Why do I need “dig +norec” to get the exact output on my slave server?
>
>
>
> Kind regards
>
> David
> --
> 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: Resolving and caching illegal names

[Greg Choules via bind-users]

Hi John.
A few questions, if I may.
- Why *must* you forward everything to Akamai?
- Was that a real example of a daft query: 10.11.12.13 type A? If not, do
you have some real examples of queries being made to your servers please?
- Notwithstanding the nature of these illegal queries, if they *are*
illegal (or misguided, or errors, or malicious, or whatever - anything but
valid), what's the issue with returning SERVFAIL? GIGO Or does that then
prejudice genuine queries, for some reason?
- Are you *only* forwarding to Akamai?
- Do you have "forward only;" or "forward first;"?
- Do Akamai have any knobs you can tweak (I believe they have a customer
web portal for viewing/changing settings?) that would make them behave like
an RFC compliant DNS server?

Cheers, Greg


On Tue, 24 Jan 2023 at 21:17, John Thurston 
wrote:

> My "resolvers" running BIND 9.18.10 and 9.16.36, accept and attempt to
> resolve queries for illegal names. They will cache answers for these names,
> and answer from cache when asked. What's the thinking here?
>
> I suppose it could be, "The specifications of what is a legal name may
> change with time, and we don't want to burden the resolver code by asking
> it to validate the string before trying to resolve it."
>
> This comes up because my "resolvers" don't actually resolve. All they are
> allowed to do is forward external queries to Akamai, and accept the
> response from Akamai. And Akamai (thank you very much), is happy to accept
> queries like "What is the A-record for 10.11.12.13?" and reply with "The
> answer is 10.11.12.13, and is good for 10 seconds."
>
> Akamai's explanation for this behavior is, ..." the query was made in
> error (likely/maybe meant to be type "PTR") and we are trying to save the
> resolver from doing the work a query like this would entail."
>
> But what it really means is my validating "resolver" then does the work of
> trying to validate the reply it got. It is unable to do so, and returns a
> SERVFAIL to the customer.
>
> I haven't yet tried, but I don't expect I can define an RPZ to trap such
> illegal names. Can I? If I could, it would reduce the traffic to Akamai,
> and the number of validations I'm trying to do.
>
>
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591john.thurs...@alaska.gov
> Department of Administration
> State of 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
>
-- 
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: recursion yes/no?

[Greg Choules via bind-users]

Hi David.
With "minimal-responses", usually I would set it to "no" for a purely
authoritative server because resolvers need all the help they can get. But
for a purely recursive server I would set it to "yes" because end users
don't need (any wouldn't do anything with it anyway) Authority or
Additional data. So a hybrid server is a bit stuck between those two
settings.

However, from 9.16 BIND now has extra choices (as Evan pointed out). To
answer your follow up question I would stick with "no-auth-recursive" as
this is exactly the scenario it is designed for.

"dig" (by default, like all stub clients) will make recursive queries; i.e.
RD=1. If your server has "minimal-responses no-auth-recursive;" set (or
nothing at all since that's the default) then a vanilla query from dig will
*not* receive anything it doesn't need to, just like real users. If you
*want* to see all the Authority and Additional data then add "+norecurse"
to your dig command, which causes it to set RD=0. Your server is then not
being asked to do recursion, so it will just reply with everything (if
anything) it has.

Hope that helps.
Greg

On Wed, 25 Jan 2023 at 10:16, David Carvalho  wrote:

> Good morning and thank you so much!
>
> Now I understand. My servers are not pure authoritative, so I’ll have to
> keep the recursion enabled.
>
> As for the answers in Authority and Additional sections, after setting
> minimal-responses to no, now I get the usual output when querying.
>
> For what I understand, there is no downside in maintaining this setting,
> right?
>
> Thank you!
>
>
>
> Kind regards.
>
> David
>
>
>
>
>
> *From:* Greg Choules 
> *Sent:* 24 January 2023 18:12
> *To:* David Carvalho 
> *Cc:* bind-users@lists.isc.org
> *Subject:* Re: recursion yes/no?
>
>
>
> Hi David.
>
> "recursion yes;" tells named that it can (if it has to) make queries to
> other places if it needs more information in order to answer a client
> query. Pure authoritative servers shouldn't need it and should have
> "recursion no;". So the first question is, do your servers make queries out
> to other places? If so, recursion must be enabled.
>
> Secondly, do you have "minimal-responses" configured on either/both
> servers? If so, what is it set to? There were changes in 9.16 so maybe
> these explain your observations.
>
>
>
> Cheers, Greg
>
>
>
> On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users <
> bind-users@lists.isc.org> wrote:
>
> Hello.
>
> I hope someone could help to understand the following.
>
> I have “my.domain.pt” and a master and slave server for the “my” part. I
> have been using “recursion yes” in both named.conf, as I want them to be
> both authoritative and cache for my clients.
>
> Last week I migrated my slave DNS server to version 9.16 and only today,
> after having issues with the primary server migration, I realized that for
> most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless
> I specify “+norec” with the dig command.
>
>
>
> My named.conf files only differ in IPs and “master/slave” setting.
>
>
>
> My questions:
>
> Should I use recursion on both? (Bear in mind that I also want them to
> provide chache to clients)
>
> Why do I need “dig +norec” to get the exact output on my slave server?
>
>
>
> Kind regards
>
> David
>
> --
> 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: Gratuitous AXFRs of RPZ after 9.18.11

[Greg Choules via bind-users]

Hi John.
Personally, I would start by drawing a picture (I like pictures) of all the
players in the game and gathering data, leaving nothing out, including:

   - All servers, with all IP addresses.
   - SOA and NS records of working zones and the troublesome RPZ zone.
   - Which servers are authoritative for each of the NS records, what
   addresses they resolve to and how the secondaries do that resolving.
   - Does the primary treat *this* secondary any differently? e.g. is it
   listed in an "also-notify" clause perhaps?
   - full configs (named-checkconf, as you have already done. But if it's
   only you looking at them, drop the "x")
   - pcaps on a working and the troublesome box (and on the primary) and a
   lot of time in Wireshark. There *must* be *something* different going on.
   *If* it turns out that 9.18.11 is behaving incorrectly, ISC will want to
   know.

HTH, Greg

On Fri, 27 Jan 2023 at 00:50, John Thurston 
wrote:

> I have a primary server and a couple of secondaries. After making
> adjustments to my RPZ yesterday (which almost never change), I noticed an
> oddity. One of my secondaries is performing gratuitous AXFRs of the RPZ.
> This isn't a huge performance issue, as my RPZ is only 7.3KB. I want to
> understand why it is doing this, when other secondaries are not and when
> this secondary is *not* also performing such gratuitous AXFRs of its
> other zones. Of note, the secondary in question has a "twin", for which the
> output of named-checkconf -px is identical (excepting the host-specific
> keys used for rndc access). That "twin" is behaving as expected.
>
> To recap, the troublesome server has several secondary zones defined. All
> but the RPZ is transferring as expected. The troublesome server has a
> "twin", which is behaving correctly for all of the secondary zones.
>
> The SOA-record for my RPZ looks like so:
>
> ;; ANSWER SECTION:
> rpz.local.  300  IN   SOA  rpz.local. hostmaster.state.ak.us. 22 3600
> 1800 432000 60
>
> And I can see my several secondaries querying the primary for the
> SOA-record on a regular basis. With a 'refresh' value in the SOA of only
> 3600, this is what I expect to see. What I don't expect to see, is the
> troublesome secondary then follows each of those queries for the SOA with
> an AXFR request, like so:
>
> 26-Jan-2023 15:25:40.175 client @0x7f19691c1280 10.213.96.197#37631/key
> from-azw (rpz.local): view azw: query: rpz.local IN SOA -SE(0)
> (10.203.163.72)
> 26-Jan-2023 15:25:40.274 client @0x7f1968118970 10.213.96.197#44769/key
> from-azw (rpz.local): view azw: query: rpz.local IN AXFR -ST (10.203.163.72)
> 26-Jan-2023 15:27:10.665 client @0x7f196925d6f0 10.213.96.197#60123/key
> from-azw (rpz.local): view azw: query: rpz.local IN SOA -SE(0)
> (10.203.163.72)
> 26-Jan-2023 15:27:10.763 client @0x7f1968118970 10.213.96.197#46011/key
> from-azw (rpz.local): view azw: query: rpz.local IN AXFR -ST (10.203.163.72)
>
> When I dump the zone database from the secondary (rndc dumpdb -zone
> rpz.local), I can see the RPZ in it with the expected serial number and
> all of the expected records.
>
> And after typing all of the above, I did an rndc status to get the
> versions of each, and discovered that the "twins" are not actually twins!
>
> The troublesome host is:9.18.11-1+ubuntu18.04.1+isc+2-Ubuntu
>
> Its "twin" is:9.18.10-1+ubuntu18.04.1+isc+1-Ubuntu
>
> And now when I study my xfer.log more closely, the behavior changed this
> morning when I  completed the update from 9.18.10 -> 9.18.11
>
> I'm not yet ready to revert, because this isn't affecting my business
> (this is a really small zone). Is anyone else seeing similar behavior?
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591john.thurs...@alaska.gov
> Department of Administration
> State of 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
>
-- 
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: Converting between zone file formats

[Greg Choules via bind-users]

Hi Håvard.
I currently have 9.18.8 installed; the version of named-compilezone is the
same. As a test I just converted a text format zone file to raw and then
that raw file back to text and it looks fine to me:
- named-compilezone -f text -F raw -o junk.raw junk db.junk
- named-compilezone -f raw -F text -o junk.raw.txt junk junk.raw

Is that what you're after? Or is it specifically whether 9.18's
interpretation of "raw" is different to 9.16's? (I don't know at the moment
and I don't have a raw file generated with 9.16 to test it).

Cheers, Greg

On Mon, 30 Jan 2023 at 10:11, Havard Eidnes via bind-users <
bind-users@lists.isc.org> wrote:

> > Named-checkzone and named-compilezone are the same executable.
> > Named-checkzone looks up remote records to more completely
> > detect configuration errors.  See the man page for details.
>
> Thanks for the hint, I apparently need to complicate my script
> even more to avoid the network lookups.
>
> You didn't answer, though, whether the 9.16 named-checkzone will
> be able to read & correctly interpret the binary zone files 9.18
> stores in the file system, or whether there is some other and
> more preferable way to accomplish what I want, either with 9.18
> itself or otherwise.
>
> Regards,
>
> - Håvard
> --
> 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: Intermittent issues resolving "labor.upload.akamai.com"

[Greg Choules via bind-users]

Hi Sandeep.
>From a quick look in Wireshark at what my own server (9.18.8) is doing,
this looks like Akamai not responding correctly to a BIND QNAME
minimisation query. Here's one response, from 95.101.36.192 for example, of
many similar ones showing an issue. The response code shouldn't be REFUSED:

Domain Name System (response)
Transaction ID: 0x87ea
Flags: 0x8005 Standard query response, Refused
1...    = Response: Message is a response
.000 0...   = Opcode: Standard query (0)
 .0..   = Authoritative: Server is not an authority for
domain
 ..0.   = Truncated: Message is not truncated
 ...0   = Recursion desired: Don't do query recursively
  0...  = Recursion available: Server can't do
recursive queries
  .0..  = Z: reserved (0)
  ..0.  = Answer authenticated: Answer/authority
portion was not authenticated by the server
  ...0  = Non-authenticated data: Unacceptable
   0101 = Reply code: Refused (5)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
_.stor.lb.akamai.net: type A, class IN
Name: _.stor.lb.akamai.net
[Name Length: 20]
[Label Count: 5]
Type: A (Host Address) (1)
Class: IN (0x0001)
Additional records
: type OPT
Name: 
Type: OPT (41)
UDP payload size: 4096
Higher bits in extended RCODE: 0x00
EDNS0 version: 0
Z: 0x8000
1...    = DO bit: Accepts DNSSEC security RRs
.000    = Reserved: 0x
Data length: 0

I haven't tested this on 9.18.10 or ..11 yet. But the behaviour of QM
hasn't changed.

I would advise you to run this on a non-production server, capture all
packets to disc and make some test queries to it until you see the issue,
to see what the server is actually doing.

I hope that helps, Greg

On Thu, 2 Feb 2023 at 23:43, Bhangui, Sandeep - BLS CTR via bind-users <
bind-users@lists.isc.org> wrote:

> Hi
>
> We are running ISC DNS Bind Version 9.18.10 ( will soon be moving to
> 9.18.11) on our Linux Servers.
>
> DNS resolution in general seems to work just fine as expected.
>
> It seems we have intermittent issues resolving "labor.upload.akamai.com"
> and then some scripts fail. It is clear that the failure of the script is
> due to DNS name lookup.
>
> Not sure if this is an issue that needs to be looked up at our end ( since
> DNS as such is working just fine for all the rest of the name resolution)
> or things are not configured properly at other end as far as how this DNS
> record is published and due to which I see the behavior of intermittent dns
> name lookup failure.
>
> Any pointers would be appreciated.
>
> Thanks
> Sandeep
>
> dig labor.upload.akamai.com
>
> ; <<>> DiG 9.18.10 <<>> labor.upload.akamai.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51211
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 17e14f79ba23179d010063dc4895fbcf47353a31763c (good)
> ;; QUESTION SECTION:
> ;labor.upload.akamai.com.   IN  A
>
> ;; Query time: 1203 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
> ;; WHEN: Thu Feb 02 18:34:45 EST 2023
> ;; MSG SIZE  rcvd: 80
>
>
> But if I point to a public DNS server like VZ or google I seem to resolve
> it fine all the time.
>
> dig @198.6.1.1 labor.upload.akamai.com
>
> ; <<>> DiG 9.18.10 <<>> @198.6.1.1 labor.upload.akamai.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43891
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;labor.upload.akamai.com.   IN  A
>
> ;; ANSWER SECTION:
> labor.upload.akamai.com. 300IN  CNAME
> labor.c-ftp.upload.akamai.com.
> labor.c-ftp.upload.akamai.com. 900 IN   CNAME
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net.
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.137
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.149
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.144
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.143
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.142
> r33674-

Re: named out of swap on NetBSD/amd64

[Greg Choules via bind-users]

Hi Jan.
There could be SO many things going on here. I have a few questions:
- Do you mean 200 QPS or 200,000 QPS? I was wondering if a "k" had missed
the print. If it's really 200, this box (not necessarily just BIND) sounds
very ill. 200 QPS is background noise and (depending what's going on)
shouldn't be close to killing a box.
- Are you stuck on 9.16.30 for some reason? If not, grab the latest 9.18
package. It will be less memory hungry generally and contain fixes for
recent issues.
- Can you give the system more memory? Real RAM, not swap. Swap is bad for
DNS generally because it's so slow.
- What does your config look like? Do you have lots of views, RPZ, stale
cache... All those things would tend to increase the memory footprint of a
busy server, depending on the query pattern.
- What sort of queries are you hitting it with?
- Have you looked at how it's handling those queries? Its path to the
Internet, for resolution, whether there are any network/firewall issues
potentially causing log jams...

Turning up debugging might show something: rndc trace 99.
If it's crashing, get a core dump and analyse that.
Try starting named and not sending it any queries at all. Just sit and
watch it, monitor the system and process memory use. etc.

That turned into a bit more than a few! I hope some of that helps a bit.
Cheers, Greg

On Sun, 12 Feb 2023 at 01:14, Jan Schaumann via bind-users <
bind-users@lists.isc.org> wrote:

> Hi,
>
> I have a local caching resolver running bind 9.16.30
> on NetBSD/amd64 9.3.
>
> I'm currently hitting it on localhost with
> approximately 200 qps, and it reliably gets killed
> after approximately 3 hours with "out of swap"
> messages in dmesg.
>
> The system in question is a Xen VPS with 6 GB RAM and
> 256 MB swap.
>
> This seems similar to the issue reported here:
> https://www.mail-archive.com/bind-users@lists.isc.org/msg30933.html
>
> (There,
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3051
> was listed as a possibly mitigating commit.)
>
> No matter how much swap I add, it eventually runs out,
> so this seems to me to suggest a leak somewhere.
>
> The relevant information about the system and version
> is below, but I was wondering what troubleshooting
> suggestions you might have.
>
>
> $ /usr/pkg/sbin/named -V
> BIND 9.16.30 (Extended Support Version) 
> running on NetBSD amd64 9.3 NetBSD 9.3
> built by make with '--with-lmdb=no'
> '--with-blacklist=yes' '--with-blocklist=no'
> '--disable-native-pkcs11' '--without-libxml2'
> '--without-libjson' '--with-readline' '--with-libtool'
> '--sysconfdir=/usr/pkg/etc' '--localstatedir=/var'
> '--with-openssl=/usr/pkg' '--with-python=no'
> '--prefix=/usr/pkg' '--build=x86_64--netbsd'
> '--host=x86_64--netbsd' '--mandir=/usr/pkg/man'
> '--enable-option-checking=yes'
> 'build_alias=x86_64--netbsd'
> 'host_alias=x86_64--netbsd' 'CC=gcc' 'CFLAGS=-O2 -fPIC
> -D_FORTIFY_SOURCE=2 -pthread -I/usr/include
> -I/usr/include/readline -I/usr/pkg/include'
> 'LDFLAGS=-Wl,-zrelro -pthread -L/usr/lib
> -Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib'
> 'LIBS=' 'CPPFLAGS=-I/usr/include
> -I/usr/include/readline -I/usr/pkg/include'
> 'PKG_CONFIG=/usr/pkg/bin/pkg-config'
> 'PKG_CONFIG_PATH='
> 'PKG_CONFIG_LIBDIR=/usr/pkg/lib/pkgconfig:/usr/pkg/share/pkgconfig'
> compiled by GCC 5.5.0
> compiled with OpenSSL version: OpenSSL 1.1.1q  5 Jul 2022
> linked to OpenSSL version: OpenSSL 1.1.1q  5 Jul 2022
> compiled with libuv version: 1.44.1
> linked to libuv version: 1.44.1
> compiled with zlib version: 1.2.10
> linked to zlib version: 1.2.10
> threads support is enabled
>
> default paths:
>   named configuration:  /usr/pkg/etc/named.conf
>   rndc configuration:   /usr/pkg/etc/rndc.conf
>   DNSSEC root key:  /usr/pkg/etc/bind.keys
>   nsupdate session key: /var/run/named/session.key
>   named PID file:   /var/run/named/named.pid
>   named lock file:  /var/run/named/named.lock
>
> $ sudo rndc status
> version: BIND 9.16.30 (Extended Support Version) 
> running on panix.netmeister.org: NetBSD amd64 9.3 NetBSD 9.3
> boot time: Sat, 11 Feb 2023 23:32:33 GMT
> last configured: Sat, 11 Feb 2023 23:32:34 GMT
> configuration file: /usr/pkg/etc/named.conf
> (/var/chroot/named/usr/pkg/etc/named.conf)
> CPUs found: 1
> worker threads: 1
> UDP listeners per interface: 1
> number of zones: 127 (97 automatic)
> debug level: 0
> xfers running: 0
> xfers deferred: 0
> soa queries in pro

Re: named out of swap on NetBSD/amd64

[Greg Choules via bind-users]

Hi Jan.
Since the queries are unique the responses should be NXDOMAIN, which *will*
be cached and therefore consume memory. This is why I was curious what you
are hitting it with.
You can see these cache entries if you dump it using "rndc dump -cache".
This produces a file (by default) called "named_dump.db" in named's working
directory. Grep for NXDOMAIN in that file.

Cheers, Greg

On Tue, 14 Feb 2023 at 15:29, Jan Schaumann via bind-users <
bind-users@lists.isc.org> wrote:

> Jan Schaumann via bind-users  wrote:
> > Greg Choules  wrote:
>
> > > - Are you stuck on 9.16.30 for some reason? If not, grab the latest
> 9.18
> > > package. It will be less memory hungry generally and contain fixes for
> > > recent issues.
> >
> > Yeah, will give that a try.
>
> Upgrading to 9.18.11 by itself did not help, but
> setting an explicit 'max-cache-size' does seem to.
>
> The queries I'm doing right now are all unique
> second-level domain queries, so no caching takes
> place, while at the same time the cache grows
> proportionally with the queries.
>
> I'm guessing that without a set 'max-cache-size', this
> continues to grow until there is no more memory space
> left, we start swapping, and eventually get OOM
> killed.
>
> https://bind9.readthedocs.io/en/v9_18_11/reference.html
> claims that the default 'max-cache-size' is 90% of
> physical memory, but it seems that didn't work out
> here.  Might it be that on NetBSD, bind doesn't
> correctly determine the physical memory amount?
>
> -Jan
> --
> 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: named out of swap on NetBSD/amd64

[Greg Choules via bind-users]

Point taken. Unique does not necessarily mean non-existent and *something*
will end up in cache. So restricting your max-cache-size would seem to be
the thing for you. If it were my server, I would monitor just how much RAM
is getting used in total and adjust max-cache-size to allow BIND to use as
much RAM as you can afford. That way you minimise the frequency of cache
cleaning, which is an overhead.

Greg

On Wed, 15 Feb 2023 at 19:45, Jan Schaumann via bind-users <
bind-users@lists.isc.org> wrote:

> Greg Choules  wrote:
>
> > Since the queries are unique the responses should be NXDOMAIN
>
> Well, _some_ of them will be NXDOMAIN, many others
> will be NOERROR or NODATA etc., no?  But yes, they all
> ended up contributing to the cache growing, and it
> seems that 90% of physical memory all in use by bind
> was simply more than my system could handle, as it
> wanted to do some other work as well. :-)
>
> -Jan
> --
> 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: Is there an incompatibility between 9.16.37/9.18.11 and 9.9 when doing HMAC-MD5 AXFR?

[Greg Choules via bind-users]

Hi Patrik. 9.9? Classic! :D
I don't believe there should be any incompatibilities. Are you perhaps
falling foul of this? From Cricket's book, chapter 11

It’s important that the name of the key—not just the binary data the key
points to— be identical on both ends of the transaction. If it’s not, the
recipient tries to verify the TSIG record and finds it doesn’t know the key
that the TSIG record says was used to compute the hash value. That causes
errors such as the following:

Jan 4 16:05:35 wormhole named[86705]: client 192.249.249.1#4666: request
has invalid signature: TSIG tsig-key.movie.edu: tsig verify failure
(BADKEY)

I'd take packet captures of both cases and compare them, see what the
differences are.
Hope that helps.
Greg

On Tue, 21 Feb 2023 at 16:06, Patrik.Graser--- via bind-users <
bind-users@lists.isc.org> wrote:

> Hi all
>
>
>
> Due to circumstances beyond my control a remote partner needs to use a
> 9.9.9 version of bind and we are required to use HMAC-MD5 for zone
> transfers. There is no (big) security concern since the networks are
> isolated and not exposed to the larger Internet.
>
>
>
> When the secondary requests an AXFR I see:
>
> client @0x nnn.nnn.nnn.nnn#xx: request has invalid
> signature: TSIG : tsig verify failure (BADSIG)
>
>
>
> Doing a dig directly (with the same key) I get the zone:
>
> client @0x nnn.nnn.nnn.nnn#xx /key  (zone.tld):
> transfer of ‘zone.tld/IN': AXFR started: TSIG  (serial )
>
>
>
> Is there any known incompatibilities – preferably with workarounds :) -
> that anyone knows about?
>
>
>
> I apologize in advance if the info is lacking but here are, what I
> consider, the relevant parts from named.conf:
>
>
>
> key "." {
>
> algorithm hmac-md5;
>
> secret "XX";
>
> };
>
>
>
> acl servers {
>
> nnn.nnn.nnn.nnn;
>
> nnn.nnn.nnn.nnn;
>
> nnn.nnn.nnn.nnn;
>
> };
>
>
>
> acl transfer {
>
> !servers;
>
> !localhost;
>
> !nnn.nnn.nnn.nnn;
>
> any;
>
> };
>
>
>
> zone "zone.tld." IN {
>
> type master;
>
> file "/etc/bind/zones/zone.file";
>
> allow-transfer { !transfer; key .; };
>
> };
>
>
>
> Again – sorry if this is insufficient information.
>
> It could be as simple as the remote not having everything in order but
> they swear up and down that they have checked, doublechecked and enlisted
> multiple persons in doing the checks.
>
>
>
> I would appreciate any and all hints even if they are farfetched.
>
>
>
> Best Regards
>
> Patrik Graeser
> --
> 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 listener to an IPv6 from AnyIP subnet

[Greg Choules via bind-users]

Hi Serg.
Can you post the output of "named -V" please?
You're looking for "--disable-linux-caps", which you don't want.

I'm not sure how (if) BIND interacts with AnyIP, but it should pick up new
interfaces as they are added, *if* it is built with the necessary
capabilities enabled. 'named' starts as root, but immediately drops to a
lower-priviliged user, which can prevent it from discovering new addresses
unless it has the necessary linux-caps.

Cheers, Greg

On Mon, 13 Mar 2023 at 09:16, Serg via bind-users 
wrote:

> The problem is I have lots of IPv6 addresses where I need to listen DNS
> requests (IPv6 prefix of /64) and I could not just explicitly add each to
> the interface, thus I use AnyIP feature to be able to use entire prefix by
> locally by such software like nginx, curl, etc.
>
> Regarding the usage of [::] - due to usage of firewall I am able to block
> connections to the 53/udp and 53/tcp which are not coming to specific IP
> addresses or ranges, I do not need such filtering functionality within bind
> itself.
>
> Anyway, the better option is to allow bind to a so known "non-local" IP
> addresses. Currently if I try to bind named to a IP address within AnyIP
> prefix but which is not explicitly added to an interface it just not bind
> socket here. Read this blog post for more details on AnyIP feature:
> https://blog.widodh.nl/2016/04/anyip-bind-a-whole-subnet-to-your-linux-machine/
>
> 2023-03-13T08:55:16Z Michael Richardson :
>
> >
> > Serg via bind-users  wrote:
> > > As an alternative approach I have tried to run with a configuration
> > > "listen-on-v6 { any; }", but it does behave in a way I need - it
> binds
> > > separate socket for each discovered IP address rather wildcard
> address
> > > of [::].
> >
> > Bind needs to bind a new socket for each address so that it can easily
> know
> > which address is being communicated with.  While there are newer ways to
> do
> > this, they aren't that portable.
> >
> > What is the problem with binding to all the addresses, if you then filter
> > which addresses will actually respond?
> >
> > Many large authoritative resolvers put the anycast address on the lo,
> and then use
> > BGP to announce connectivity, and AFAIK, they all just listen on all
> > addresses, because sometimes you want to ask a specific server a
> question.
> --
> 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: RPZ answer me NXDOMAIN for some domain

[Greg Choules via bind-users]

Hi Nath.
What have you got on SrvB for biopyrenees.net, or net?
On SrvB, please do "dig @127.0.0.1 sri.biopyrenees.net" (please use the
actual address rather than "localhost") and paste the full result here. I
am interested in flags and the query time right now.

Cheers, Greg

On Wed, 22 Mar 2023 at 11:52, BONIN Nathanael  wrote:

> Hi there,
>
>
>
> We are using RPZ zone for some times now, but recently we found a weird
> behavior from some domains. Let me explain !
>
>
>
> We have 2 NS server : Recursive one (let’s call him SrvA) and one bebind
> (let’s call him SrvB, with global forwarder : SrvA ). My RPZ zone is on
> SrvA.
>
>
>
> If we took a little diagram, we have :
>
>
>
> User = > SrvB = > SrvA = > Internet
>
>
>
> If we create an A record tatata.google.com / 2.3.4.5 (that doesn’t exist
> at google.com) on RPZ zone :
>
>
>
>- On SrvA with : dig @localhost tatata.google.com we got IP : 2.3.4.5
>=> GREAT !
>- On SrvB with : dig @localhost tatata.google.com (that point on
>SrvA), we got IP : 2.3.4.5 => WONDERFUL !
>
>
>
> BUT
>
>
>
> If we create another A record sri.biopyrenees.net / 3.4.5.6 (that doesn’t
> exist at biopyrenees.net) on RPZ zone :
>
>
>
>- On SrvA with : dig @localhost sri.biopyrenees.net, we got IP :
>3.4.5.6 => YOUPI !
>- On SrvB with : dig @localhost sri.biopyrenees.net, we got : NXDOMAIN
>=> WHA ?
>
>
>
> Why for some domain, the RPZ isn’t working ?
>
>
>
> An exemple of what I wrote on my RPZ zone :
>
>
>
> tatata.google.com   A   2.3.4.5
>
> sri.biopyrenees.net A  3.4.5.6
>
>
>
> Is it normal ? Is there a way to have the good answer on my SrvB ?
>
>
>
> With tcpdump, I see the same behavior with a record that works and with
> the record that doesn’t work…
>
>
>
> Thanks for your help.
>
>
>
> Nath.
>
>
>
>
>
>
>
>
>
>
> --
> 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 with qname min. fails to continue recursing on one specific query

[Greg Choules via bind-users]

Hi Jason.
I just tried this on my server (9.18.11) and it does indeed appear to be
qname minimisation. The following servers (NS for tn.gov) just don't
respond to the query "_.edison.tn.gov":

dns4.tn.gov: type A, class IN, addr 170.141.167.222
dns5.tn.gov: type A, class IN, addr 170.141.168.22

QM can't be disabled per destination server, only globally.
I would recommend you contact the NS administrators and inform them they
have a problem. According to the SOA the RNAME is
named-...@wannms.state.tn.us

Cheers, Greg

On Mon, 27 Mar 2023 at 18:54,  wrote:

> Hi,
>
> Recursive queries to a pair of matching bind 9.16 servers on openbsd 7.0
> are timing out unexpectedly for only two names: "www.edison.tn.gov" and "
> www.tn.gov". Both bind instances are otherwise working fine, and have
> been for some time.
>
> The query returns a CNAME, and there's a delegation to another set of
> nameservers on tn.gov, but as you can see below in the pcap and the
> named.run excerpt, bind never seems to follow up.
>
> If I disable qname minimization this is no longer an issue, but I'd rather
> not, and I don't understand the behavior at all.
>
> Queries for either tn.gov subdomain from other hosts on other networks to
> which I have access (all using Unbound for recursion unfortunately) are
> working as expected. And I'm seeing no other unexplained failures. I keep
> thinking I should be able to find some other domain which will trigger this
> behavior, but haven't yet.
>
> According to users this has been going on since last Wednesday or late
> last Friday. The domains were resolving week before last based on my own
> experience, but I don't have logs from more than a few days ago, so I can't
> demonstrate that conclusively.
>
> There's some relevant text from named.run below, also a bit of a packet
> capture, and I'm happy to supply whatever else may be helpful. Trimmed
> named.conf just a bit, marked where I've done so. All material is from
> before I thought to turn off qname minimisation.
>
> I'm totally lost, any thoughts or suggestions are very very welcome.
>
> Thanks,
>
> Jason
>
>
> ### named.conf:
>
> acl internals {
> 127.0.0.0/8;
> 10.0.0.0/8;
> 172.16.28.0/24;
> 128.25.10.0/24;
> 172.16.20.16/28;
> };
>
> acl nameservers {
> 172.16.20.23/32;
> 172.16.20.22/32;
> 172.16.20.30/32;
> };
>
> logging {
>   channel rpz.log {
> file "/var/log/rpz.log" versions 3 size 5m;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
>   };
>   channel updates.log {
> file "/var/log/ddns.log" versions 3 size 5m;
> severity info;
> print-time yes;
> print-severity yes;
> print-category yes;
>   };
>   channel query.log {
> file "/var/log/query.log" versions 1 size 5m;
> severity debug 3;
> print-time yes;
> print-severity yes;
> print-category yes;
>   };
>   category queries { query.log; };
>   category update { updates.log;  };
>   category rpz { rpz.log; };
>   category lame-servers { null; };
>   category edns-disabled { null; };
> };
>
> options {
>   directory "/tmp";
>   listen-on { 172.16.20.22; 172.16.20.30; };
>   check-names master warn ;
>   allow-transfer { nameservers; };
>   also-notify { 172.16.20.30; 172.16.20.23; };
>   allow-query { any; };
>   allow-recursion { internals; };
>   recursion 1;
>   dnssec-validation no;
>   #dnssec-validation auto;
>   #response-policy { zone rpz.local; };
>   #response-policy { zone rpz.local; } break-dnssec yes;
> };
>
> key "example.org" {
> # trimmed
> };
>
> key "rndc-key" {
> # trimmed
> };
>
> key "external" {
> # trimmed
> };
>
> controls {
>   inet 127.0.0.1 port 953
>   allow { 127.0.0.1; } keys { "rndc-key"; };
> };
>
> view "internal" {
>   match-clients { !key external; internals; };
>   allow-recursion { internals; };
>   allow-query { any; };
>   recursion yes;
>   zone "." {
>   type hint;
>   file "/etc/named.ca";
>   };
>   #zone "rpz.local" {
>   #  type master;
>   #  file "/master/rpz.local.hosts";
>   #  allow-query { localhost; };
>   #  allow-transfer { nameservers; };
>   #  notify yes;
>   #};
>   zone "example.org" {
>   type master;
> file "/master/example.org.internal.hosts";
> allow-update { key "example.org"; }

Re: Best practice MultiView

[Greg Choules via bind-users]

Hi Jiaming.
The arguments to "also-notify {...};" are explicit IP addresses.

Why do you need it? Do you have some secondaries that are not listed as NS
in zones?

Regarding views. Why would you have the same zone in an internal and
external view? A few years ago, having to maintain multiple zones of the
same name but different contents caused me problems daily. I would
recommend having internal zones be proper delegations from external zones.
e.g.:
external "example.com"
internal "internal.example.com"

Cheers, Greg

On Mon, 17 Apr 2023 at 14:41, Jiaming Zhang  wrote:

> Dear Nick,
>
> Thanks for the reply. What was already set that I didn't include in my
> first mail was that both views on both servers have match-clients​ set
> (for internal set to "localhost" and "localnets", and for external set to
> "any"), so I'll add the keys also to the match-clients​.
>
> However, I got a question on the syntax of also-notify​, what I can see
> from bind9's user manual, the target of also-notify​ can be 
> |  [ port  ] |  [ port  ]​,
> does this means that I can use domain names of the server instead of IP?
> Both name server has IPv4 (single or multiple) and IPv6 glued with the
> domain name, and I was wondering if by setting domain name instead of IP,
> bind will intelligently find if it would need to communicate with which IP
> (like it currently do with notify yes​). I asked because if by any chance
> for whatever reason sending notify was failed to a certain IP, it may look
> up any other available IP that is defined with the related domain name (at
> least from my observation).
>
> I was also confused what you exactly referred to with '"primaries" (or
> "masters" in old terminology) statement that includes the correct key
> name', I assume you mean I need to point which is the master and the keys
> to communicate with this specific master on the slave server. For the
> reference, I attached the related config on slave below.
>
> ```
> zone "example.com" IN {
> type slave;
> masters { ; };
> file "/path/to/file";
> allow-query { any; };
> notify yes; # will become "explicit"
> };
> ```
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* bind-users  namens Nick Tait via
> bind-users 
> *Verzonden:* maandag, april 17, 2023 1:03 PM
> *Aan:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
>
> Hi Jiaming.
>
> You'll also need "match-clients" in the first view (at least), so that the
> correct view handles the zone transfer request. As well as specifying 'the
> right key' in match-clients, you'll probably also want to specify 'not the
> wrong key', otherwise you won't be able to query the view from any clients
> (e.g. on your internal network) that don't present any key in their
> request...
>
> I've taken your example, and changed the key names to "
> internal.example.com" and "external.example.com" (for clarity), and added
> the match-clients to it as follows:
>
> view "internal" {
>   match-clients { key "internal.example.com"; !key "external.example.com";
> internal-networks; };
>   zone "example.com" IN {
> # some other config, master zone
> allow-transfer { key "internal.example.com"; };
> notify yes;
>   };
>   # some more zone
> };
> view "external" {
>   match-clie

Re: Best practice MultiView

[Greg Choules via bind-users]

Hi Jiaming.
I had a similar requirement. Since there were not many (a few tens or at
most a hundred) names that needed to be resolved differently locally my
approach was to create a zone for each of them and to not have the parent
zone at all. Each specific zone would contain a single A record (or maybe
others) with the owner name being @ or tha name of the zone.
e.g.:
EXTERNAL zone
example.com
INTERNAL zones
insite.example.com
   @ A 10.1.1.1
another.example.com
   @ A 10.1.1.2
etc...
This way, the default is for all resolution to go externally, except the
names you want to resolve internally with different answers.

Cheers, Greg

On Tue, 18 Apr 2023 at 12:59, Jiaming Zhang  wrote:

> Dear Greg,
>
> The initiative was that we have certain records that wish to be view only
> internally and may resolve to private address (e.g. insite A 10.1.1.1​).
>
> Kind Regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Monday, April 17, 2023 4:43:58 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
> The arguments to "also-notify {...};" are explicit IP addresses.
>
> Why do you need it? Do you have some secondaries that are not listed as NS
> in zones?
>
> Regarding views. Why would you have the same zone in an internal and
> external view? A few years ago, having to maintain multiple zones of the
> same name but different contents caused me problems daily. I would
> recommend having internal zones be proper delegations from external zones.
> e.g.:
> external "example.com"
> internal "internal.example.com"
>
> Cheers, Greg
>
> On Mon, 17 Apr 2023 at 14:41, Jiaming Zhang  wrote:
>
> Dear Nick,
>
> Thanks for the reply. What was already set that I didn't include in my
> first mail was that both views on both servers have match-clients​ set
> (for internal set to "localhost" and "localnets", and for external set to
> "any"), so I'll add the keys also to the match-clients​.
>
> However, I got a question on the syntax of also-notify​, what I can see
> from bind9's user manual, the target of also-notify​ can be 
> |  [ port  ] |  [ port  ]​,
> does this means that I can use domain names of the server instead of IP?
> Both name server has IPv4 (single or multiple) and IPv6 glued with the
> domain name, and I was wondering if by setting domain name instead of IP,
> bind will intelligently find if it would need to communicate with which IP
> (like it currently do with notify yes​). I asked because if by any chance
> for whatever reason sending notify was failed to a certain IP, it may look
> up any other available IP that is defined with the related domain name (at
> least from my observation).
>
> I was also confused what you exactly referred to with '"primaries" (or
> "masters" in old terminology) statement that includes the correct key
> name', I assume you mean I need to point which is the master and the keys
> to communicate with this specific master on the slave server. For the
> reference, I attached the related config on slave below.
>
> ```
> zone "example.com" IN {
> type slave;
> masters { ; };
> file "/path/to/file";
> allow-query { any; };
> notify yes; # will become "explicit"
> };
> ```
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://

Re: Best practice MultiView

[Greg Choules via bind-users]

Hi Jiaming.

Every zone *must* have one SOA record and at least one NS record. This is a
requirement of the protocol.
Internal clients will (probably) be making recursive queries to the
internal DNS server for A, , MX, SRV records (maybe some more types as
well). It is unlikely they will be making queries for NS records normally.
But what if they do? Why does it matter if clients find out the NS names
for the internal zones?

Cheers, Greg

On Tue, 18 Apr 2023 at 13:27, Jiaming Zhang  wrote:

> Dear Greg,
>
> I agree using child zones is a better idea, and I'm actually using this,
> what I want to hide is the NS records of the internal-only subdomains. OR
> is the NS record totally unnecessary if the DNS resolver has these
> individual zones (which I don't think so based on how DNS query works).
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Tuesday, April 18, 2023 2:10:49 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
> I had a similar requirement. Since there were not many (a few tens or at
> most a hundred) names that needed to be resolved differently locally my
> approach was to create a zone for each of them and to not have the parent
> zone at all. Each specific zone would contain a single A record (or maybe
> others) with the owner name being @ or tha name of the zone.
> e.g.:
> EXTERNAL zone
> example.com
> INTERNAL zones
> insite.example.com
>@ A 10.1.1.1
> another.example.com
>@ A 10.1.1.2
> etc...
> This way, the default is for all resolution to go externally, except the
> names you want to resolve internally with different answers.
>
> Cheers, Greg
>
> On Tue, 18 Apr 2023 at 12:59, Jiaming Zhang  wrote:
>
> Dear Greg,
>
> The initiative was that we have certain records that wish to be view only
> internally and may resolve to private address (e.g. insite A 10.1.1.1​).
>
> Kind Regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Monday, April 17, 2023 4:43:58 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
> The arguments to "also-notify {...};" are explicit IP addresses.
>
> Why do you need it? Do you have some secondaries that are not listed as N

Re: Fully automated DNSSEC with BIND 9.16

[Greg Choules via bind-users]

Hi Håvard
Odd, it works for me. Try a literal copy/paste of the link below. Or go to
https://kb.isc.org and search for packages:

https://kb.isc.org/docs/isc-packages-for-bind-9

Cheers, Greg

On Wed, 19 Apr 2023 at 12:03, Havard Eidnes via bind-users <
bind-users@lists.isc.org> wrote:

> >>and if I run straight "upstream" code, it's fairly straight-
> >>forward to upgrade to this version, modulo, of course, the fact
> >>that this involves building it from source.
> >
> > It may not be necessary to build from source.  There are packages for
> > some distros maintained by ISC
> > (https://kb.isc.org/docs/isc-packages-for-bind-9).
>
> I stand corrected, thanks for reminding me.  I come from the
> non-Linux open source side, so needs this reminder from time to
> time.
>
> BTW, if someone from ISC is listening in, the above KB URL
> currently returns
>
>The request is blocked.
>
>  
> 04Mk/ZADbZIhApAs8So/u0PGqLpjUU1ZHMjBFREdFMDYyMgAxMTU1ZGM4Yy1kNzdiLTQ3YzQtOThjNS02NzBhNjQ3MGRhNzE=
>
> Best regards,
>
> - Håvard
> --
> 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: Best practice MultiView

[Greg Choules via bind-users]

Hi Jiaming.
Here's what I would do. I am assuming one nameserver for the public zone
and one (different) nameserver for the internal zones. You would use more
in practice but I'm keeping it simple, for illustration.

The external NS is reachable from anywhere in the Internet. If you host it
in your own network, ideally do it on a public DMZ. It hosts one zone;
example.com. The NS name is externalns.example.com.

The internal NS is *not* reachable from anywhere in the Internet, only to
internal hosts and probably on a private address (depends on your internal
addressing scheme). It hosts three zones; internal1.example.com,
internal2.example.com, internal3.example.com. The name of the NS itself is
internalns.internal1.example.com


EXTERNAL NS
zone: example.com
@ SOA
@ NS externalns
internal1 NS internalns.internal1
internal2 NS internalns.internal1
internal2 NS internalns.internal1
other records...


INTERNAL NS
zone internal1.example.com
@ SOA
@ NS internalns
internalns A 192.168.1.1
other records

zone internal2.example.com
@ SOA
@ NS internalns.internal1.example.com.
other records

zone internal3.example.com
@ SOA
@ NS internalns.internal1.example.com.
other records


>From an Internet source, the only NS that can be reached is
externalns.example.com. Queries could be made to it to learn that
delegations exist for the internal zones and the name of the NS for those
zones. However, they cannot resolve the IP address of internalns. Not that
it would help anyway if it's 192.168.something and/or your firewalls block
incoming DNS.

It is not essential to have the delegations in externalns because internal
clients do not use them anyway. However, it is recommend to have them
because a) it is technically correct and b) it will be necessary for DNSSEC
validation to work internally.

Hope that helps.
Greg

On Wed, 19 Apr 2023 at 18:20, Jiaming Zhang  wrote:

> Dear Greg,
>
> That’s what I thought, of each individual zone must have NS record point
> to it. But my point is not hiding NS record (or which server handles it)
> from internal client but hiding which internal domain are we running from
> the external malicious client.
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Tuesday, April 18, 2023 2:51:05 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
>
> Every zone *must* have one SOA record and at least one NS record. This is
> a requirement of the protocol.
> Internal clients will (probably) be making recursive queries to the
> internal DNS server for A, , MX, SRV records (maybe some more types as
> well). It is unlikely they will be making queries for NS records normally.
> But what if they do? Why does it matter if clients find out the NS names
> for the internal zones?
>
> Cheers, Greg
>
> On Tue, 18 Apr 2023 at 13:27, Jiaming Zhang  wrote:
>
> Dear Greg,
>
> I agree using child zones is a better idea, and I'm actually using this,
> what I want to hide is the NS records of the internal-only subdomains. OR
> is the NS record totally unnecessary if the DNS resolver has these
> individual zones (which I don't think so based on how DNS query works).
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoe

Re: Best practice MultiView

[Greg Choules via bind-users]

Hi Jiaming.
You're welcome.

Personally I don't see why you want to obscure information about internal
zones, since they can't be reached from the Internet anyway.
Creating a dummy intermediate zone (an ENT - Empty Non-Terminal) may work,
but it seems to add complexity for no - or very little - benefit. Just my
2p.

Cheers, Greg

On Fri, 21 Apr 2023 at 15:41, Jiaming Zhang  wrote:

> Hi Greg,
>
> Thanks for the example given. I was trying to digest your answer, it seems
> it would be better to have intermediate subdomain for the purpose. So it
> will be site1.internal.example.com, site2.internal.example.com, etc. and
> thus only NS records of internal.example.com can be visible and not the
> actual internally operating site. Now it just a matter of migration from
> site_n.example.com to site_n.internal.example.com. (which I suppose is
> also better for DNSSEC)
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (6) 12 98 08 07*
> *Email: j.zh...@yiximeta.com *
>
>
> *Website: yiximeta.com <http://yiximeta.com> De informatie in dit bericht
> is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de
> bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld
> ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te
> informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of
> informatie uit deze e-mail is alleen toegestaan met voorafgaande
> schriftelijke toestemming van de afzender. Het Yixi Meta staat
> geregistreerd bij de Kamer van Koophandel in het handelsregister onder
> nummer 85744115. The content of this message is intended solely for the
> addressee. No rights can be derived from this message or its attachments.
> If you are not the intended recipient, we kindly request you to delete the
> message and inform the sender. It is strictly prohibited to disclose, copy
> or distribute this email or the information inside it, without a written
> consent from the sender. Yixi Meta is registered with the Dutch Chamber of
> Commerce trade register with number 85744115.*
> --
> *Van:* Greg Choules 
> *Verzonden:* Wednesday, April 19, 2023 11:01:00 PM
> *Aan:* Jiaming Zhang 
> *CC:* bind-users@lists.isc.org 
> *Onderwerp:* Re: Best practice MultiView
>
> Hi Jiaming.
> Here's what I would do. I am assuming one nameserver for the public zone
> and one (different) nameserver for the internal zones. You would use more
> in practice but I'm keeping it simple, for illustration.
>
> The external NS is reachable from anywhere in the Internet. If you host it
> in your own network, ideally do it on a public DMZ. It hosts one zone;
> example.com. The NS name is externalns.example.com.
>
> The internal NS is *not* reachable from anywhere in the Internet, only to
> internal hosts and probably on a private address (depends on your internal
> addressing scheme). It hosts three zones; internal1.example.com,
> internal2.example.com, internal3.example.com. The name of the NS itself
> is internalns.internal1.example.com
>
>
> EXTERNAL NS
> zone: example.com
> @ SOA
> @ NS externalns
> internal1 NS internalns.internal1
> internal2 NS internalns.internal1
> internal2 NS internalns.internal1
> other records...
>
>
> INTERNAL NS
> zone internal1.example.com
> @ SOA
> @ NS internalns
> internalns A 192.168.1.1
> other records
>
> zone internal2.example.com
> @ SOA
> @ NS internalns.internal1.example.com.
> other records
>
> zone internal3.example.com
> @ SOA
> @ NS internalns.internal1.example.com.
> other records
>
>
> From an Internet source, the only NS that can be reached is
> externalns.example.com. Queries could be made to it to learn that
> delegations exist for the internal zones and the name of the NS for those
> zones. However, they cannot resolve the IP address of internalns. Not that
> it would help anyway if it's 192.168.something and/or your firewalls block
> incoming DNS.
>
> It is not essential to have the delegations in externalns because internal
> clients do not use them anyway. However, it is recommend to have them
> because a) it is technically correct and b) it will be necessary for DNSSEC
> validation to work internally.
>
> Hope that helps.
> Greg
>
> On Wed, 19 Apr 2023 at 18:20, Jiaming Zhang  wrote:
>
> Dear Greg,
>
> That’s what I thought, of each individual zone must have NS record point
> to it. But my point is not hiding NS record (or which server handles it)
> from internal client but hiding which internal domain are we running from
> the external malicious client.
>
> Kind regards,
> Jiaming Zhang
>
> *Yixi Meta*
> *Tel: +31 (

Re: bind9 (9.18.14) build / install on macOS Ventura (13.3.1) fails to create dirs or files as expected

[Greg Choules via bind-users]

Hello.
By far the simplest way to install BIND natively on Mac is to use the
Homebrew package manager. I have 9.18.14 installed on mine and it works
fine.
The other alternative is to run it from the Docker image. See here for
details: https://hub.docker.com/r/internetsystemsconsortium/bind9

Hope that helps.
Greg

On Tue, 9 May 2023 at 21:43, Pacific  wrote:

> Installing bind9 (9.18.14) on macOS Ventura (13.3.1) — install is not
> creating a namedb directory nor can I find a boilerplate named.conf.
>
> Steps taken:
>
> Downloaded tar directly from isc, saved to a local directory as a user
> with admin privs.
>
> Steps to build:
>
> *tar xzf bind-9.18.14.tar.gz*
>
> *cd bind-9.18.14*
>
> *./configure*
>
>
> Config summary reads:
>
> *=*
>
> *Configuration summary:*
>
> *-*
>
> *Optional features enabled:*
>
> *Memory allocator: jemalloc*
>
> *GSS-API (--with-gssapi)*
>
> *DNSSEC validation active by default (--enable-auto-validation)*
>
> *-*
>
> *Features disabled or unavailable on this platform:*
>
> *Small-system tuning (--with-tuning)*
>
> *Allow 'dnstap' packet logging (--enable-dnstap)*
>
> *GeoIP2 access control (--enable-geoip)*
>
> *DNS Response Policy Service interface (--enable-dnsrps)*
>
> *Allow 'fixed' rrset-order (--enable-fixed-rrset)*
>
> *Very verbose query trace logging (--enable-querytrace)*
>
> *Single-query trace logging (--enable-singletrace)*
>
> *LMDB database to store configuration for 'addzone' zones (--with-lmdb)*
>
> *IDN support (--with-libidn2)*
>
> *-*
>
> *Configured paths:*
>
> *prefix: /usr/local*
>
> *sysconfdir: ${prefix}/etc*
>
> *localstatedir: ${prefix}/var*
>
> **
>
> *Compiler: gcc*
>
> *Apple clang version 14.0.3 (clang-1403.0.22.14.1)*
>
> *Target: arm64-apple-darwin22.4.0*
>
> *Thread model: posix*
>
> *InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin*
>
> *CFLAGS: -Wall -Wextra -Wwrite-strings -Wpointer-arith 
> -Wno-missing-field-initializers -Wformat -Wshadow 
> -Werror=implicit-function-declaration -Werror=missing-prototypes 
> -Werror=format-security -Werror=parentheses -Werror=implicit 
> -Werror=strict-prototypes -Werror=vla -fno-strict-aliasing 
> -fno-delete-null-pointer-checks -fdiagnostics-show-option -g -O2 -pthread 
> -Wno-deprecated-declarations*
>
> *CPPFLAGS: -D_FORTIFY_SOURCE=2 -I/opt/homebrew/opt/openssl@3/include*
>
> *LDFLAGS: -L/opt/homebrew/opt/openssl@3/lib*
>
> *—*
>
> After configure completes:
>
> *make*
>
> When make successfully completes, ran test suite:
>
> *sudo ./bin/tests/system/ifconfig.sh up *
>
> *make test*
>
> Tests run clean, bring down interface and do make install which runs to 
> completion:
>
> *sudo ./bin/tests/system/ifconfig.sh down*
>
> *sudo make install*
>
> Install appears to complete successfully, however there is no namedb 
> directory in either /etc or /usr/local/etc
>
> In fact there is no named.conf file anywhere on the system except in the
> source tree.
>
> Please advise as to where to look or please advise if there are additional
> build steps to take, if configure needs edits, etc.
>
> Thanks for any assistance.
>
> --
> 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: bind9 (9.18.14) build / install on macOS Ventura (13.3.1) fails to create dirs or files as expected

[Greg Choules via bind-users]

The named binary *could* exist in many places; it depends on the OS. For
example, with a Homebrew install on my Mac it's here:
/usr/local/Cellar/bind/9.18.14/sbin/named because of this build parameter:
--prefix=/usr/local/Cellar/bind/9.18.14
It's linked to from /usr/local/opt/bind/sbin/named, for convenience.

I don't recall whether you get an example "named.conf" Mine is here, by the
way:
/usr/local/etc/bind/named.conf because of this build parameter:
--sysconfdir=/usr/local/etc/bind

Again, search for a named.conf and if you don't have one, 'touch' it to
create it then try running it. By default it doesn't need to contain
anything, just exist. The built-in defaults are enough to get a server
running.
As you start to customise your config, keep an eye on the log, which will
tell you whether named starts or not and if not, why. Then you can correct
errors and try again.

I don't think it should matter that artefacts from a previous install
attempt are hanging around. But before you try installing it another way I
would search for files called "named":
sudo find / -name named
and see if you have a binary. In my case:
%file /usr/local/sbin/named
/usr/local/sbin/named: Mach-O 64-bit executable x86_64

If you find an executable, do /named -V (uppercase V), which will
print a summary of how it was built.
Similarly /named -C (uppercase) will print the defaults.

Hope this helps.
Greg


On Wed, 10 May 2023 at 05:55, Pacific  wrote:

> Hi, thanks for the reply.
>
> For some reason I thought it did install or drop a base bones named.conf
> file, however, it should have dropped the named binary into /usr/local  —
> which it didn’t do. And none of the other “various BIND 9 libraries”.
>
> The bind docs at
> https://bind9.readthedocs.io/en/latest/chapter10.html#build-bind
>
> in section 10.2 on building show this:
>
> make install installs named
> <https://bind9.readthedocs.io/en/latest/manpages.html#std-iscman-named> and
> the various BIND 9 libraries. By default, installation is into /usr/local,
> but this can be changed with the --prefix option when running configure.
>
> The option --sysconfdir can be specified to set the directory where
> configuration files such as named.conf
> <https://bind9.readthedocs.io/en/latest/manpages.html#std-iscman-named.conf> 
> go
> by default; --localstatedir can be used to set the default parent
> directory ofrun/named.pid. --sysconfdir defaults to $prefix/etc and
> --localstatedir defaults to $prefix/var.
> If I’m missing something please let me know - or if you have any
> suggestions, like just moving the named binary from my temp dir into
> /usr/local I’d appreciate. Thanks.
>
> On May 9, 2023, at 5:08 PM, Anand Buddhdev  wrote:
>
> On 09/05/2023 22:23, Pacific wrote:
>
> Hi Pacific,
>
> Installing bind9 (9.18.14) on macOS Ventura (13.3.1) — install is
> not  creating a namedb directory nor can I find a boilerplate named.conf.
>
>
> As far as remember, the bind install procedure doesn't create a named.conf.
>
> --
> Anand
>
>
> --
> 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: resolver: DNS format error from

[Greg Choules via bind-users]

Hi Alex.
TL;DR 9.18 is stricter than 9.16 at handling junk responses from
authoritative servers.

Looking at a packet capture for this from my own BIND server (9.18.14) the
response from 195.178.56.17 is FORMERR, which tends to mean that it objects
to something in the query. The correct response to something you don't like
is to ignore it, so this server is not obeying protocol and 9.18 is not
going to try and work around broken behaviour.

I disabled sending of cookies to this server and now it works. It could be
that it doesn't like cookies, or just any EDNS option that it doesn't know
what to do with. Either way, it should be fixed.

Hope that helps.
Greg



On Tue, 16 May 2023 at 15:53, Alex  wrote:

> Hi,
> I have a bind-9.18.7 system on fedora37 and having some strange errors
> with some queries.
>
> $ host info.apr.gov.rs
> Host info.apr.gov.rs not found: 2(SERVFAIL)
>
> in my bind logs I have the following:
> 16-May-2023 10:37:49.800 resolver: DNS format error from 195.178.56.17#53
> resolving ns1.apr.gov.rs/ for : server sent FORMERR
> 16-May-2023 10:37:49.800 lame-servers: received FORMERR resolving '
> ns1.apr.gov.rs//IN': 195.178.56.17#53
> 16-May-2023 10:37:49.800 lame-servers: timed out resolving '
> info.apr.gov.rs/A/IN': 212.62.49.194#53
> 16-May-2023 10:37:49.800 query-errors: client @0x7f9d546d5168
> 127.0.0.1#59712 (info.apr.gov.rs): query failed (failure) for
> info.apr.gov.rs/IN/A at ../../../lib/ns/query.c:7717
>
> In the limited search results I've found for this, I believe it has
> something to do with dnssec or EDNS, but I really don't know how to
> troubleshoot this. Is this a known problem?
>
> It also appears to be happening with even hosts like ticketmaster?
> 16-May-2023 10:21:09.348 lame-servers: FORMERR resolving '
> engage.ticketmaster.com/NS/IN': 205.251.194.123#53
>
> The host resolves fine on my bind-9.16.38 system using the exact same
> configuration, as well as most or all public resolvers.
>
>
>
>
>
>
>
>
>
> --
> 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: thank you - Re: bind9 (9.18.14) build / install on macOS Ventura (13.3.1) fails to create dirs or files as expected

[Greg Choules via bind-users]

You are most welcome, I'm glad you got it running. Now the fun starts! :D

Greg

On Tue, 30 May 2023 at 21:02, Pacific  wrote:

> Thank you and to everyone who took the time to respond. Your collective
> input did the trick and I now have bind running successfully through a brew
> install.
>
> I got pulled into another project and wanted to reply with thanks sooner.
> Your time is valuable and I sincerely appreciate everyone who took the time
> to make suggestions.
>
> On May 10, 2023, at 1:39 AM, Greg Choules <
> gregchoules+bindus...@googlemail.com> wrote:
>
> The named binary *could* exist in many places; it depends on the OS. For
> example, with a Homebrew install on my Mac it's here:
> /usr/local/Cellar/bind/9.18.14/sbin/named because of this build parameter:
> --prefix=/usr/local/Cellar/bind/9.18.14
> It's linked to from /usr/local/opt/bind/sbin/named, for convenience.
>
> I don't recall whether you get an example "named.conf" Mine is here, by
> the way:
> /usr/local/etc/bind/named.conf because of this build parameter:
> --sysconfdir=/usr/local/etc/bind
>
> Again, search for a named.conf and if you don't have one, 'touch' it to
> create it then try running it. By default it doesn't need to contain
> anything, just exist. The built-in defaults are enough to get a server
> running.
> As you start to customise your config, keep an eye on the log, which will
> tell you whether named starts or not and if not, why. Then you can correct
> errors and try again.
>
> I don't think it should matter that artefacts from a previous install
> attempt are hanging around. But before you try installing it another way I
> would search for files called "named":
> sudo find / -name named
> and see if you have a binary. In my case:
> %file /usr/local/sbin/named
> /usr/local/sbin/named: Mach-O 64-bit executable x86_64
>
> If you find an executable, do /named -V (uppercase V), which will
> print a summary of how it was built.
> Similarly /named -C (uppercase) will print the defaults.
>
> Hope this helps.
> Greg
>
>
> On Wed, 10 May 2023 at 05:55, Pacific  wrote:
>
>> Hi, thanks for the reply.
>>
>> For some reason I thought it did install or drop a base bones named.conf
>> file, however, it should have dropped the named binary into /usr/local  —
>> which it didn’t do. And none of the other “various BIND 9 libraries”.
>>
>> The bind docs at
>> https://bind9.readthedocs.io/en/latest/chapter10.html#build-bind
>>
>> in section 10.2 on building show this:
>>
>> make install installs named
>> <https://bind9.readthedocs.io/en/latest/manpages.html#std-iscman-named> and
>> the various BIND 9 libraries. By default, installation is into /usr/local,
>> but this can be changed with the --prefix option when running configure.
>>
>> The option --sysconfdir can be specified to set the directory where
>> configuration files such as named.conf
>> <https://bind9.readthedocs.io/en/latest/manpages.html#std-iscman-named.conf> 
>> go
>> by default; --localstatedir can be used to set the default parent
>> directory ofrun/named.pid. --sysconfdir defaults to $prefix/etc and
>> --localstatedir defaults to $prefix/var.
>> If I’m missing something please let me know - or if you have any
>> suggestions, like just moving the named binary from my temp dir into
>> /usr/local I’d appreciate. Thanks.
>>
>> On May 9, 2023, at 5:08 PM, Anand Buddhdev  wrote:
>>
>> On 09/05/2023 22:23, Pacific wrote:
>>
>> Hi Pacific,
>>
>> Installing bind9 (9.18.14) on macOS Ventura (13.3.1) — install is
>> not  creating a namedb directory nor can I find a boilerplate named.conf.
>>
>>
>> As far as remember, the bind install procedure doesn't create a
>> named.conf.
>>
>> --
>> Anand
>>
>>
>> --
>> 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: replace "SERVFAIL" to "NXDOMAIN" with rpz

[Greg Choules via bind-users]

Hi Sami.
Firstly, a couple of definitions:
NXDOMAIN is a response from an authoritative server (or a resolver because
it cached it). It is a positive confirmation that "this name does not
exist". It means that the QNAME in the query cannot be found, for any
record type.
SERVFAIL is a response from a recursive server meaning "I tried my best to
get a response to your query but I just failed".

So if your monitoring tool, whatever it is, is receiving SERVFAIL responses
from your DNS server then you need to fix whatever is causing those in the
server.
Causes of SERVFAIL could be that your server cannot contact the
authoritative server(s) that should know the answer. Or it might be because
your server is trying to do DNSSEC validation and that is failing.
The best way to know *why* you are getting SERVFAIL would be to take a
packet capture that includes the client queries to the server and any
queries the server makes to try and get answers, plus all the responses.
Please do that and share the results, using real domains, not examples.

Hope that helps, Greg


On Mon, 19 Jun 2023 at 09:39,  wrote:

> Hello Thank you for your feedback,
> yes it works like that!  for that does not work for a domain name that
> already has the return code "SERVFAIL" and we want to change this code by
> "NXDDOMAIN" like this domain name "antlauncher.com"
> regards Rahal
>
> -Message d'origine-
> De : bind-users  De la part de
> bind-users-requ...@lists.isc.org
> Envoyé : samedi 17 juin 2023 06:23
> À : bind-users@lists.isc.org
> Objet : bind-users Digest, Vol 4262, Issue 1
>
> Send bind-users mailing list submissions to
> bind-users@lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
> bind-users-requ...@lists.isc.org
>
> You can reach the person managing the list at
> bind-users-ow...@lists.isc.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>1. replace "SERVFAIL"  to "NXDOMAIN"  with rpz
>   (sami.ra...@sofrecom.com)
>2. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Crist Clark)
>3. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Fred Morris)
>4. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Ond?ej Sur?)
>
>
> --
>
> Message: 1
> Date: Fri, 16 Jun 2023 20:39:43 +
> From: sami.ra...@sofrecom.com
> To: "bind-users@lists.isc.org" 
> Subject: replace "SERVFAIL"  to "NXDOMAIN"  with rpz
> Message-ID: <9c4465dc103645149093f4d3f60cf...@sofrecom.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Hello
> For monitoring reasons I try to change the return code of a domain name
> from "SERVFAIL" to "NXDOMAIN" with the rpz classic configuration of
> BIND9.16.42 as follows:
> example.com IN CNAME.
> *.example.com IN CNAME .
> But it still doesn't work, I still have the message  " SERVFAIL", is it
> feasible or not please ?
> Kind regards
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.isc.org/pipermail/bind-users/attachments/20230616/aa23b454/attachment-0001.htm
> >
>
> --
>
> Message: 2
> Date: Fri, 16 Jun 2023 20:29:16 -0700
> From: Crist Clark 
> To: sami.ra...@sofrecom.com
> Cc: "bind-users@lists.isc.org" 
> Subject: Re: replace "SERVFAIL" to "NXDOMAIN" with rpz
> Message-ID:
>  ozrfq_scazbn-ruz...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> That should return a NXDOMAIN. Returning SERVFAIL is never a normal RPZ
> action. Something is wrong with your configuration.
>
> On Fri, Jun 16, 2023 at 1:39?PM  wrote:
>
> >
> >
> > Hello
> >
> > For monitoring reasons I try to change the return code of a domain
> > name from "SERVFAIL" to "NXDOMAIN" with the rpz classic configuration
> > of
> > BIND9.16.42 as follows:
> >
> > example.com IN CNAME.
> >
> > *.example.com IN CNAME .
> >
> > But it still doesn't work, I still have the message  " SERVFAIL", is
> > it feasible or not please ?
> >
> > Kind regards
> >
> >
> > --
> > Visit https://lists.isc.org/mailman/listinfo/bind-users to u

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

[Greg Choules via bind-users]

That's because this domain is broken. The NS for it are:

antlauncher.com: type NS, class IN, ns ns1626.ztomy.com (204.11.56.26)
antlauncher.com: type NS, class IN, ns ns2626.ztomy.com (204.11.57.26)

No matter what query you send them (so far) they respond with REFUSED and
claim not to be authoritative for "antlauncher.com".

Personally I would live with the SERVFAIL because it tells you that
something is wrong, not just that it doesn't exist. Then try to contact the
people who own this domain and tell them it is broken.

Cheers, Greg

On Mon, 19 Jun 2023 at 10:33,  wrote:

> Hello
>
> Thank you for these details Greg, by the way I worked on a problem on one
> of my resolvers and there are no errors of type "SERVFAIL" currently for
> valid domain names but I receive servfail for this domain name "
> antlauncher.com" that's why I wanted to change the return code for this
> domain name to "NXDOMAIN" so as not to distort the monitoring result .
>
> Regards
>
> *De :* Greg Choules 
> *Envoyé :* lundi 19 juin 2023 10:03
> *À :* RAHAL Sami SOFRECOM 
> *Cc :* bind-users@lists.isc.org
> *Objet :* Re: replace "SERVFAIL" to "NXDOMAIN" with rpz
>
>
>
> Hi Sami.
>
> Firstly, a couple of definitions:
>
> NXDOMAIN is a response from an authoritative server (or a resolver because
> it cached it). It is a positive confirmation that "this name does not
> exist". It means that the QNAME in the query cannot be found, for any
> record type.
>
> SERVFAIL is a response from a recursive server meaning "I tried my best to
> get a response to your query but I just failed".
>
>
>
> So if your monitoring tool, whatever it is, is receiving SERVFAIL
> responses from your DNS server then you need to fix whatever is causing
> those in the server.
>
> Causes of SERVFAIL could be that your server cannot contact the
> authoritative server(s) that should know the answer. Or it might be because
> your server is trying to do DNSSEC validation and that is failing.
>
> The best way to know *why* you are getting SERVFAIL would be to take a
> packet capture that includes the client queries to the server and any
> queries the server makes to try and get answers, plus all the responses.
>
> Please do that and share the results, using real domains, not examples.
>
>
>
> Hope that helps, Greg
>
>
>
>
>
> On Mon, 19 Jun 2023 at 09:39,  wrote:
>
> Hello Thank you for your feedback,
> yes it works like that!  for that does not work for a domain name that
> already has the return code "SERVFAIL" and we want to change this code by
> "NXDDOMAIN" like this domain name "antlauncher.com"
> regards Rahal
>
> -Message d'origine-
> De : bind-users  De la part de
> bind-users-requ...@lists.isc.org
> Envoyé : samedi 17 juin 2023 06:23
> À : bind-users@lists.isc.org
> Objet : bind-users Digest, Vol 4262, Issue 1
>
> Send bind-users mailing list submissions to
> bind-users@lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
> bind-users-requ...@lists.isc.org
>
> You can reach the person managing the list at
> bind-users-ow...@lists.isc.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>1. replace "SERVFAIL"  to "NXDOMAIN"  with rpz
>   (sami.ra...@sofrecom.com)
>2. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Crist Clark)
>3. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Fred Morris)
>4. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Ond?ej Sur?)
>
>
> --
>
> Message: 1
> Date: Fri, 16 Jun 2023 20:39:43 +
> From: sami.ra...@sofrecom.com
> To: "bind-users@lists.isc.org" 
> Subject: replace "SERVFAIL"  to "NXDOMAIN"  with rpz
> Message-ID: <9c4465dc103645149093f4d3f60cf...@sofrecom.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Hello
> For monitoring reasons I try to change the return code of a domain name
> from "SERVFAIL" to "NXDOMAIN" with the rpz classic configuration of
> BIND9.16.42 as follows:
> example.com IN CNAME.
> *.example.com IN CNAME .
> But it still doesn't work, I still have the message  " SERVFAIL", is it
> feasible or not please ?
>

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

[Greg Choules via bind-users]

Hi Sami.
That's not what I said.
Yes, you can do this with RPZ if you want - it's all in the BIND ARM - but
it's not something I would do.

Cheers, Greg

On Mon, 19 Jun 2023 at 12:40,  wrote:

> Thank you Greg
>
> So if I understand correctly if we receive a servfail return code we can
> not modify this code by nxdomain with the rpz configuration?
>
> Regards
>
>
>
> *De :* Greg Choules 
> *Envoyé :* lundi 19 juin 2023 12:02
> *À :* RAHAL Sami SOFRECOM 
> *Cc :* bind-users@lists.isc.org
> *Objet :* Re: replace "SERVFAIL" to "NXDOMAIN" with rpz
>
>
>
> That's because this domain is broken. The NS for it are:
>
> antlauncher.com: type NS, class IN, ns ns1626.ztomy.com (204.11.56.26)
>
> antlauncher.com: type NS, class IN, ns ns2626.ztomy.com (204.11.57.26)
>
> No matter what query you send them (so far) they respond with REFUSED and
> claim not to be authoritative for "antlauncher.com".
>
>
>
> Personally I would live with the SERVFAIL because it tells you that
> something is wrong, not just that it doesn't exist. Then try to contact the
> people who own this domain and tell them it is broken.
>
>
>
> Cheers, Greg
>
>
>
> On Mon, 19 Jun 2023 at 10:33,  wrote:
>
> Hello
>
> Thank you for these details Greg, by the way I worked on a problem on one
> of my resolvers and there are no errors of type "SERVFAIL" currently for
> valid domain names but I receive servfail for this domain name "
> antlauncher.com" that's why I wanted to change the return code for this
> domain name to "NXDOMAIN" so as not to distort the monitoring result .
>
> Regards
>
> *De :* Greg Choules 
> *Envoyé :* lundi 19 juin 2023 10:03
> *À :* RAHAL Sami SOFRECOM 
> *Cc :* bind-users@lists.isc.org
> *Objet :* Re: replace "SERVFAIL" to "NXDOMAIN" with rpz
>
>
>
> Hi Sami.
>
> Firstly, a couple of definitions:
>
> NXDOMAIN is a response from an authoritative server (or a resolver because
> it cached it). It is a positive confirmation that "this name does not
> exist". It means that the QNAME in the query cannot be found, for any
> record type.
>
> SERVFAIL is a response from a recursive server meaning "I tried my best to
> get a response to your query but I just failed".
>
>
>
> So if your monitoring tool, whatever it is, is receiving SERVFAIL
> responses from your DNS server then you need to fix whatever is causing
> those in the server.
>
> Causes of SERVFAIL could be that your server cannot contact the
> authoritative server(s) that should know the answer. Or it might be because
> your server is trying to do DNSSEC validation and that is failing.
>
> The best way to know *why* you are getting SERVFAIL would be to take a
> packet capture that includes the client queries to the server and any
> queries the server makes to try and get answers, plus all the responses.
>
> Please do that and share the results, using real domains, not examples.
>
>
>
> Hope that helps, Greg
>
>
>
>
>
> On Mon, 19 Jun 2023 at 09:39,  wrote:
>
> Hello Thank you for your feedback,
> yes it works like that!  for that does not work for a domain name that
> already has the return code "SERVFAIL" and we want to change this code by
> "NXDDOMAIN" like this domain name "antlauncher.com"
> regards Rahal
>
> -Message d'origine-
> De : bind-users  De la part de
> bind-users-requ...@lists.isc.org
> Envoyé : samedi 17 juin 2023 06:23
> À : bind-users@lists.isc.org
> Objet : bind-users Digest, Vol 4262, Issue 1
>
> Send bind-users mailing list submissions to
> bind-users@lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
> bind-users-requ...@lists.isc.org
>
> You can reach the person managing the list at
> bind-users-ow...@lists.isc.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>1. replace "SERVFAIL"  to "NXDOMAIN"  with rpz
>   (sami.ra...@sofrecom.com)
>2. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Crist Clark)
>3. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Fred Morris)
>4. Re: replace "SERVFAIL" to "NXDOMAIN" with rpz (Ond?ej Sur?)
>
>
> -

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

[Greg Choules via bind-users]

>From the correct email alias this time!

On Mon, 19 Jun 2023 at 16:50, Greg Choules 
wrote:

> Hi Lee/Sami.
> `break-dnssec yes;` *may* also be needed in some cases. But not here as
> the zone isn't signed anyway.
>
> The reason that "example.com" works but "antlauncher.com" doesn't is down
> to BIND needing to perform recursion and get an answer before RPZ kicks in
> and overwrites it (unless you specify `qname-wait-recurse no;`). "
> example.com" actually gets an answer (from IANA) but "antlauncher.com"
> gets REFUSED.
>
> Wireshark it and see.
>
> By the way, I have been testing this on 9.18.15
> Cheers, Greg
>
>
> On Mon, 19 Jun 2023 at 16:10, Lee  wrote:
>
>> On 6/19/23, sami.rahal wrote:
>> > Thank you Greg
>> >
>> > I tested with other domain name to replace "SERVFAIL" with "NXDOMAIN"
>> is it
>> > not working
>>
>> You're missing "break-dnssec yes" on your response-policy stanza?
>> You need something like
>>   response-policy { zone "rpz.mozilla"; zone "rpz.zone"; }
>>  break-dnssec yes
>>  recursive-only no
>>  qname-wait-recurse no;
>>   #enable rpz
>>   # By default, RPZ actions are applied only to DNS requests that either
>> do not
>>   # request DNSSEC metadata (DO=0) or when no DNSSEC records are
>> available for
>>   # request name in the original zone (not the response policy zone).
>>   # This default can be changed for all response policy zones in a view
>> with a
>>   # break-dnssec yes clause. In that case, RPZ actions are applied
>> regardless
>>   # of DNSSEC.
>>   #
>>   # zone "rpz.mozilla";
>> #
>> https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
>>
>> Regards,
>> Lee
>>
>> >
>> > I use CentOS7 with BIND9.16.41
>> >
>> >
>> >
>> > grep antlauncher db.rpz
>> >
>> > antlauncher.com CNAME   .
>> >
>> > *.antlauncher.com   CNAME   .
>> >
>> >
>> >
>> > grep example db.rpz
>> >
>> > example.com IN  CNAME   .
>> >
>> > *.example.com   IN  CNAME   .
>> >
>> >
>> >
>> > dig @0 foo.antlauncher.com
>> >
>> >
>> >
>> > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> @0
>> > foo.antlauncher.com ; (1 server found) ;; global options: +cmd ;; Got
>> > answer:
>> >
>> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54704 ;; flags: qr
>> rd
>> > ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>> >
>> >
>> >
>> > ;; OPT PSEUDOSECTION:
>> >
>> > ; EDNS: version: 0, flags:; udp: 4096
>> >
>> > ;; QUESTION SECTION:
>> >
>> > ;foo.antlauncher.com.   IN  A
>> >
>> >
>> >
>> > ;; Query time: 241 msec
>> >
>> > ;; SERVER: 127.0.0.1#53(0.0.0.0)
>> >
>> > ;; WHEN: Mon Jun 19 10:52:22 CET 2023
>> >
>> > ;; MSG SIZE  rcvd: 48
>> >
>> >
>> >
>> > # dig @0 example.com
>> >
>> >
>> >
>> > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> @0 example.com
>> ; (1
>> > server found) ;; global options: +cmd ;; Got answer:
>> >
>> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9852 ;; flags: qr
>> rd
>> > ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
>> >
>> >
>> >
>> > ;; OPT PSEUDOSECTION:
>> >
>> > ; EDNS: version: 0, flags:; udp: 4096
>> >
>> > ;; QUESTION SECTION:
>> >
>> > ;example.com.   IN  A
>> >
>> >
>> >
>> > ;; ADDITIONAL SECTION:
>> >
>> > siteblockeddb.  1   IN  SOA LOCALHOST.
>> > need.to.know.only. 2016011100 43200 900 1814400 7200
>> >
>> >
>> >
>> > ;; Query time: 347 msec
>> >
>> > ;; SERVER: 127.0.0.1#53(0.0.0.0)
>> >
>> > ;; WHEN: Mon Jun 19 10:52:36 CET 2023
>> >
>> > ;; MSG SIZE  rcvd: 115
>> >
>> >
>> >
>> >
>> > De : Greg Choules 
>> > Envoyé : lundi 19 juin 2023 15:12
>&

Re: latency and response time

[Greg Choules via bind-users]

Hi Sami.
Let me ask you a question.

How would you define the terms "latency" and "response time"?

Greg

On Tue, 27 Jun 2023 at 17:23,  wrote:

> Hello In DNS benchmarking  which is more important latency or response
> time? for a DNS server what is the difference between the two values?
>
>
>
> Regards, Sami
> --
> 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: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Greg Choules via bind-users]

Hi Ubence.
Firstly, may we see your configs please. It's impossible to say exactly
what's going on from a human description.

Secondly, views and different answers. Yes it *is* entirely possible to use
views to provide answers based on client IP - `match-clients. I would start
with the most specific view first with a `match-clients` clause, then a
general view without one. If you only have two choices.

Thirdly, naming of multi-homed systems. A long time ago, in a previous job,
I tried to work out how to make (say) "system.lab.domain.com" resolve to
different addresses, depending on who was asking the question, or from
which direction they were asking it and it nearly drove me mad. I concluded
that "sytem" should not be regarded as one domain, but one domain *per
interface*.
So let's say that the box called "system" has two interfaces with addresses
192.168.10.170 for its lab side and 10.32.10.1 for its production side. I
would do this and not bother with views:

zone "domain.com" {
   type primary;
   file "db.domain.com";
};

Contents at least:
@ SOA etc...
@   IN   NS   
lab   IN   NS  ;don't forget the delegation
system   IN   A   10.32.10.1

zone "lab.domain.com" {
   type primary;
   file "db.lab.domain.com";
};

Contents at least:
@ SOA etc...
@   IN   NS   
system   IN   A   10.32.10.1

Now to reach "system", depending on who you are, which direction you are
approaching it from and what network routeing and firewalls will allow you
either connect to "system.domain.com" for its production side or
system.lab.domain.com" for its lab side. There is no ambiguity about what
address "system" has because each one now has a unique name.

Note that this requires clients to use FQDNs, which IMHO is a good thing. I
always try to avoid "search" in resolv.conf because it leaves the OS
stub resolver guessing what the user actually wants.


Hope that helps. But as i said, configs please and then *we* don't have to
guess :)
Cheers, Greg


On Wed, 28 Jun 2023 at 23:45, Ubence Quevedo  wrote:

> Hi,
>
> I have two domains configured, a production and lab/testing domain [let's
> say domain.com and lab.domain.com].
>
> I have a few different networks configured [192.168.10.0/24 and
> 10.32.10.0/24].
>
> I have a system that has two network cards on both the 192.168.10.X
> network and 10.32.10.X network.
>
> I have a remote system that is also configured to on both networks, with
> hostnames on both domains/networks.
>
> I have a hostname entry in my primary master for the domain.com [
> system.lab.domain.com/192.168.10.170], but there are other systems
> configured via the bind 9 system that serves out lab.domain.com with an
> entry for this system [system.lab.domain.com/10.32.10.1].
>
> On the primary DNS server, the system.lab.domain.com worked great and
> pointed to 192.168.10.170, however I made the lab server a secondary on the
> primary and vice-a-versa so that the lab.domain.com entries would resolve
> for systems on the 192.168.10.X network so that the dual network capable
> system would be able to resolve lab hostnames from my primary DNS server.
> This is a Mac and the primary interface wins for name resolution as far as
> I can tell even though the other network interface is configured to point
> to the lab DNS server.
>
> This makes things work great to be able to resolve lab network host names,
> but the 10.32.10.X network isn't directly accessible to the 192.168.10.X
> network.
>
> What's happening is the that hostname I have configured on the primary
> name server [system.lab.domain.com/192.168.10.170] is not taking
> precedence over the secondary domain that is configured [
> system.lab.domain.com/10.32.10.1].
>
> Any resolution now for the system.lab.totusmel.coml hostname now brings
> back 10.32.10.1 instead of the 192.168.10.170.
>
> I think it's because the lab domain takes precedence because the domain
> name lab.domain.com is a higher priority than domain.com even with the
> system.lab tacked onto the primary domain.
>
> I started dabbling with views and tried to set up specific views that
> would return a fully qualified hostname as a domain based on what network
> the request came from.  If the request came from the 10.32.10.X network,
> return the system.lab.domain.com/10.32.10.1 entry and if it came from the
> 192.168.10.X network, return the system.lab.domain.com/192.168.10.170
> entry.
>
> This seemed to work after re-arranging the order of the main configuration
> file, and I could resolve the system.lab.domain.com as 192.168.10.170 as
> I intended but this then broke all of the host entries I had configured for
> domain.com as none were resolvable.
>
>
>

Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Greg Choules via bind-users]

Hi Ubence.
That is starting to get complex!

Firstly, yes BIND parses views top down, so order matters.
Secondly, most specific domain wins (like more specific routes).

I now see that you have created three levels of zones:
domain.com
lab.domain.com
system.lab.domain.com

This config looks like it's from the 10... primary, correct? Can you send
the config from 192.168.10.183 as well please?
What zones does it have and are there views on it too?

Rather than speculate why adding that secondary zone has started the
problems, dump the database - rndc dumpdb -all - and see what it contains.
That should show you what the server thinks it should be doing. Also, check
the logs for what got transferred.

I don't understand the purpose of both lab.domain.com and
system.lab.domain.com, unless the intention is to provide a general zone
for all things 'lab' and a set of more specific zones for just this system?


I stand by my opinion that I still wouldn't use views for this and that the
way to do it is to give every numbered interface on every machine its own
domain.
So if "system" has six addresses it has six FQDNs, each one in a different
zone. That alone may sound at first like it is complicating matters, but
consider this: each address exists for a reason and in a different network
(or you wouldn't need a different address), so a domain suffix can be
viewed as the domain for a given network and all interfaces of all devices
that sit in that network share a domain suffix.

If "system" is the end host itself I wouldn't give it its own zone. It's
not illegal (and can actually be useful in some edge cases), just overly
complicated. If this were my network I'd do something like:

zone "domain.com" {
type primary;
#contains delegations for net1, net2...net6

zone "net1.domain.com" {
# 192.168.10.0/24
etc...

zone "net2.domain.com" {
# 10.32.1.0/24
etc...

zone "net3.domain.com" {
# 10.32.10.0/24
etc...

zone "net4.domain.com" {
# 10.32.20.0/24
etc...

zone "net5.domain.com" {
# 10.32.30.0/24
etc...

zone "net6.domain.com" {
# ?.?.?.?
etc...

"system" has A records in all of these, with the relevant interface address
for the network. Clients lookup the FQDN of interest to them at the time.
This way there is guaranteed no ambiguity.

Cheers, Greg


On Thu, 29 Jun 2023 at 15:00, Ubence Quevedo  wrote:

> Hi Greg,
>
> Here's the most recent config that I tried that seemed to work, but
> ultimately broke resolution for the main zone domain.com, even though I
> set it to match-clients { any; }.
>
> What I didn't mention in my original post was that I have other subnets
> configured for this remote host through vlans with different IP addresses.
> That's why there are so many other views.  I was hoping the match-clients
> per each view would return the appropriate IP address per subnet making the
> request.
>
> include "/etc/bind/rndc.key";
> include "/etc/bind/ddns-key.key";
>
> view "192.168.10-net" {
>   match-clients { 192.168.10.0/24; };
>   zone "system.lab.domain.com" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.192.168.10";
> };
> };
>
> view "10.32.1-net" {
>   match-clients { 10.32.1.0/24; };
>   zone "system.lab.domain.com" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.1";
> };
> };
>
> view "10.32.10-net" {
>   match-clients { 10.32.10.0/24; };
>   zone "system.lab.domain.com" {
> type master;
>file "/var/lib/bind/db.system.lab.domain.com.10.32.10";
> };
> };
>
> view "10.32.20-net" {
>   match-clients { 10.32.20.0/24; };
>   zone "system.lab.domain.com" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.20";
> };
> };
>
> view "10.32.30-net" {
> match-clients { 10.32.30.0/24; };
>   zone "system.lab.domain.com" {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.30";
> };
> };
>
> view "main" {
>   match-clients { any; };
>   zone "domain.com" {
> type master;
> forwarders {};
> file "/var/lib/bind/db.domain.com";
> update-policy {
>   grant ddns-key wildcard *.domain.com A DHCID;
> };
> notify yes;
> allow-transfer { 192.168.10.183; };
> };
>   zone "lab.domain.com" {
> type secondary;
> masterfile-format text;
> file "/var/lib/bind/db.lab.domain.com";
> primaries { 192.168.10.183; };
>   };
>   zone "10.168.192.in-addr.arpa&

Re: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Greg Choules via bind-users]

Hi.
Ah, I got the networks the wrong way round.

Sorry, it wasn't until I saw Sten's response that it occurred to me that
not everyone knows how views work. Indeed a query will be tested against
each view, top down. If it satisfies the criteria for a view (either/both
match-clients and match-destinations) it stops there. If that view can't
answer, sorry. No further views are tested. This is why the 'any' view is
last, like a default route.

Having system10/system-10, system20, system30 etc.. or some such naming
convention, all in "lab.domain.com" will certainly work. The goal is
uniqueness. How you achieve it is down to preference.

I have an additional thought about primaries and secondaries. In my
experience, unless there are completely different teams who don't talk much
to each other running separate DNS servers, it is best to keep all your
primary zones in one place (or two for resilience). It makes it easier to
administer and to understand which way data is flowing.

Cheers, Greg

On Thu, 29 Jun 2023 at 16:14, Ubence Quevedo  wrote:

> Hi,
>
> Actually, that config was from the primary at 192.168.10.3.
>
> Below is the config from the lab DNS server at 10.32.1.6/192.168.10.183:
> include "/etc/bind/rndc.key";
> include "/etc/bind/ddns-key.key";
>
> zone "lab.domain.com" {
>   type master;
>   forwarders {};
>   file "/var/lib/bind/db.lab.domain.com";
>   update-policy {
> grant ddns-key wildcard *.lab.domain.com A DHCID;
>   };
>   notify yes;
>   allow-transfer { 192.168.10.3; };
> };
>
> zone "domain.com" {
>   type secondary;
>   masterfile-format text;
>   file "/var/lib/bind/db.domain.com";
>   primaries { 192.168.10.3; };
> };
>
> zone "1.32.10.in-addr.arpa" {
>   type master;
>   forwarders {};
>   file "/var/lib/bind/db.1.32.10.in-addr.arpa";
>   update-policy {
> grant ddns-key wildcard *.domain.com A DHCID;
>   };
> };
>
> zone "10.32.10.in-addr.arpa" {
>   type master;
>   forwarders {};
>   file "/var/lib/bind/db.10.32.10.in-addr.arpa";
>   update-policy {
> grant ddns-key wildcard *.10.32.10.in-addr.arpa PTR;
>   };
> };
>
> zone "20.32.10.in-addr.arpa" {
>   type master;
>   forwarders {};
>   file "/var/lib/bind/db.20.32.10.in-addr.arpa";
>   update-policy {
> grant ddns-key wildcard *.20.32.10.in-addr.arpa PTR;
>   };
> };
>
> zone "30.32.10.in-addr.arpa" {
>   type master;
>   forwarders {};
>   file "/var/lib/bind/db.30.32.10.in-addr.arpa";
>   update-policy {
> grant ddns-key wildcard *.30.32.10.in-addr.arpa PTR;
>   };
> };
>
> I now realize that views is *NOT* what I want to do since it's either one
> view or the other not an and type of thing.
>
> The reason I was trying to do just both domain.com and lab.domain.com is
> that I have let's encrypt certificates setup through both domain names.
> Doing the net2.domain.com, net3.domain.com, etc. I think would mean that
> I'd need certificates for each of those zones.
>
> However, I think if I just slightly change the hostname for the
> lab.domain.com like system10.lab.domain.com, system20.lab.domain.com,
> etc. and have those setup with different IP addresses, that *should* work.
> No ambiguity there since it's an entirely different hostname being resolved
> and still keep the lab.domain.com domain name.
>
> Ultimately, views won't work, which is very clear now, but having distinct
> hostnames for each instance on a different subnet *should* work and could
> be put on the lab.domain.com system so that when they are replicated to
> the primary name server they will resolve appropriately.
>
> Does that sound about right?
>
> On Thu, Jun 29, 2023 at 7:53 AM Greg Choules <
> gregchoules+bindus...@googlemail.com> wrote:
>
>> Hi Ubence.
>> That is starting to get complex!
>>
>> Firstly, yes BIND parses views top down, so order matters.
>> Secondly, most specific domain wins (like more specific routes).
>>
>> I now see that you have created three levels of zones:
>> domain.com
>> lab.domain.com
>> system.lab.domain.com
>>
>> This config looks like it's from the 10... primary, correct? Can you send
>> the config from 192.168.10.183 as well please?
>> What zones does it have and are there views on it too?
>>
>> Rather than speculate why adding that secondary zone has started the
>> problems, dump the database - rndc dumpdb -all - and see what it contains.
>> That should show you what the server thinks it should be doing. Also, check
>> the 

Re: extended dns error

[Greg Choules via bind-users]

Hi Sami.
In the "response-policy" block in your config, what (if anything) is the
value of the statement "qname-wait-recurse"?
If you do not have that set explicitly, please do "named -C" to list the
defaults and see what it is; probably "yes".

This parameter controls whether RPZ waits until successful recursion has
finished before it rewrites the response, according to the matching rule in
the RPZ zone.
If there is no successful response from recursion then RPZ has nothing to
rewrite, so your server's response to its client will be SERVFAIL.

It looks like your server cannot resolve cadyst.com/A for some reason,
which would explain what gets sent back to the client.
However, it resolves fine for me:
cadyst.com. 908 IN A 146.59.209.152

Maybe you have some other issue with your resolver?

Cheers, Greg

On Wed, 12 Jul 2023 at 09:26,  wrote:

> Hello
>  Thank you for your answer yes we will plan a migration to version 9.18.
> now I have activated "error log" to have the cause of an error servfail is
> here is the result.
>
> 11-Jul-2023 10:36:21.146 query-errors: debug 3: client @0x7f217a2bd250
> 127.0.0.1#39627 (cadyst.com): view default: rpz QNAME rewrite cadyst.com
> stop on qresult in rpz_rewrite(): timed out
> 11-Jul-2023 10:36:21.146 query-errors: debug 1: client @0x7f217a2bd250
> 127.0.0.1#39627 (cadyst.com): view default: query failed (timed out) for
> cadyst.com/IN/A at query.c:8042
> 11-Jul-2023 10:36:21.146 query-errors: debug 4: fetch completed at
> resolver.c:4983 for cadyst.com/A in 10.000118: timed out/success [domain:
> cadyst.com
> ,referral:0,restart:3,qrysent:6,timeout:5,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
>
> Regards Sami
>
>
> Message: 2
> Date: Tue, 11 Jul 2023 12:04:15 +0200
> From: Matthijs Mekking 
> To: bind-users@lists.isc.org
> Subject: Re: extended dns error
> Message-ID: <6f5bb3dc-ddf0-873c-c630-fa89fe260...@isc.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Upgrade to 9.18, because 9.16 does not support extended DNS errors.
>
> See
>
>
> https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_date&state=all&label_name%5B%5D=Extended%20DNS%20Errors&first_page_size=20
>
> For which errors are supported.
>
> Best regards, Matthijs
>
> On 7/11/23 11:10, sami.ra...@sofrecom.com wrote:
> > Hello ?community
> >
> > I want to use "extended dns error" option on my recursive dns server.
> > What config changes are required to enable EDE?
> >
> > I am using BIND 9.16.42 as recursive server.
> >
> > Regards Sami
> >
> >
>
>
> --
>
> Subject: Digest Footer
>
> ___
> 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
>
>
> --
>
> End of bind-users Digest, Vol 4279, Issue 3
> ***
> --
> 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 to Bind DNS Lookup - Returns wildcard value for defined A record

[Greg Choules via bind-users]

Real data please:
- example queries (genuine, not invented for illustration)
- real domains
- real IP addresses
- packet captures
- both BIND server configs
- zone file contents
- startup logs

There are so many things it *could* be, the more information the better.

Cheers, Greg

On Sun, 16 Jul 2023 at 09:09, OwN-3m-All  wrote:

> I've got a bind recursion DNS server setup that is returning the wrong
> value for an outside domain that I also maintain and host on another server
> running a bind DNS server.  Yet Google's DNS and other major DNS providers
> respond with the correct IP address A record when querying.  I can't figure
> out why my recursion enabled instance is not returning the correct IP
> address for a specific host.  Rather, it returns the wildcard value from
> the zonefile rather than the specifically specified A record entry created
> for that host.
>
> It appears bind to bind is returning the wildcard value for a specifically
> defined host in the zonefile from the server it's hosted on.
>
> Is this a recent bug in bind?  More information about my setup and issue
> can be found here:
>
>
> https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entr
>
> From what I found online, if there's a specific host A record entry
> defined, it should always return that IP.  Wildcard is only for those not
> defined.  Yet, when I remove the wildcard from the zonefile, my bind
> recursion instance returns the correct value, but not when the wildcard
> entry is there.  But Google and other major DNS providers return the
> non-wildcard value as expected.
>
> Any help is appreciated.
> --
> 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 to Bind DNS Lookup - Returns wildcard value for defined A record

[Greg Choules via bind-users]

This time from the correct email alias!

On Mon, 17 Jul 2023 at 22:58, Greg Choules 
wrote:

> Hi.
> Some observations:
> - Please don't use nslookup. Please use dig, it is much more versatile and
> gives much more information with which to try and interpret what might be
> going on.
> - If you're going to specify a destination server please use its IP
> address, not its domain name (dnsr.dinofly.com). The reason for this is
> that if you use a domain, first that domain needs to be resolved to an IP
> address by the OS, which may or may not work, or may not give the result
> you were expecting.
> - I did a dig for "specific.wildcard-test.dynx.me" against my own BIND
> server and it resolved to 1.1.1.1. So the issue is with your resolver. This
> is not new, just confirming that this must be the problem end, not the auth
> end.
> - Please paste *the entire* config of your resolver, not just bits
> that you think might be important. "named-checkconf -px" will produce that.
> - Please run tcpdump on your resolver for port 53, captured to disc, then
> download and analyse it in Wireshark. Only by seeing what your server does
> after it receives your dig will you understand how it is attempting to find
> an answer, which should shed some light on why you get the response you do.
> That is, if you DO get the same answer using dig (@IP) rather than nslookup
> (at domain).
>
> Cheers, Greg
>
> On Mon, 17 Jul 2023 at 20:36, OwN-3m-All  wrote:
>
>> Spam assassin is blocking my message, so here are all the details (my
>> latest response message):
>>
>> https://pastebin.com/raw/jSm6aGfC
>> --
>> 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: help me with the ipv6 PTR generation

[Greg Choules via bind-users]

You may already have BIND installed; most distros do. If not, it's easy.
You don't *have* to run named, but tools like this (and dig, particularly)
are very useful to have.

Do "which arpaname" to see if you have it already.

Cheers, Greg

On Thu, 24 Aug 2023 at 08:00, Marco  wrote:

> Am 24.08.2023 schrieb Jan-Piet Mens :
>
> > easier said than done, for some of us. I use BIND's arpaname(1)
> > utility which does the work for me:
> >
> > $ arpaname 2001:db8::1
> > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
>
> Thanks for telling me. I used dig and extracted the question section.
>
> Sadly, arpaname is in bind9 package, so if I wanna use it, I have to
> install bind.
> --
> 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: Facing issues while resolving only one record

[Greg Choules via bind-users]

Hi Blason.
"incometax.gov.in" is a domain known to cause problems. Take a binary
packet capture and look at it in Wireshark. Also see this
https://dnsviz.net/d/incometax.gov.in/dnssec/

A workaround in BIND is to disable DNSSEC validation for just that domain
whilst leaving it on generally: see below.
DNSSEC validation is on ("auto") by default these days. Please don't turn
it off for everything.

options {
...
validate-except {
incometax.gov.in;
...
};
...
};

Hope this helps.
Greg

On Wed, 30 Aug 2023 at 14:20, Blason R  wrote:

> Hi all,
>
> I have bind BIND 9.18.17-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support
> Version)
> And I am facing this weird issue. Somehow eportal.incometax.gov.in site
> is not getting resolved through DNS.
>
> I tried a lot but unfortunately the issue still persists.
>
> Here are packet capture logs.
>
> listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length
> 262144 bytes
> 18:47:19.56 ens18 In  IP 192.168.1.162.61110 > 192.168.1.133.53: 20+
> A? eportal.incometax.gov.in. (42)
> 18:47:19.587705 ens18 Out IP 192.168.1.133.40263 > 208.67.222.222.53:
> 30627+% [1au] A? eportal.incometax.gov.in. (65)
> 18:47:19.599214 ens18 Out IP 192.168.1.133.44299 > 1.1.1.1.53: 62952+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:20.800736 ens18 Out IP 192.168.1.133.56154 > 8.8.8.8.53: 16152+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:21.573628 ens18 In  IP 192.168.1.162.53536 > 192.168.1.133.53: 21+
> ? eportal.incometax.gov.in. (42)
> 18:47:21.576427 ens18 Out IP 192.168.1.133.55356 > 8.8.8.8.53: 57361+%
> [1au] ? eportal.incometax.gov.in. (65)
> 18:47:22.002738 ens18 Out IP 192.168.1.133.33064 > 208.67.222.222.53:
> 16204+% [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:22.777934 ens18 Out IP 192.168.1.133.58739 > 208.67.222.222.53:
> 34205+% [1au] ? eportal.incometax.gov.in. (65)
> 18:47:23.20 ens18 Out IP 192.168.1.133.60920 > 9.9.9.9.53: 46145+%
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:23.584820 ens18 In  IP 192.168.1.162.53962 > 192.168.1.133.53: 22+
> A? eportal.incometax.gov.in. (42)
> 18:47:24.405041 ens18 Out IP 192.168.1.133.56475 > 198.41.0.4.53: 12349
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.205136 ens18 Out IP 192.168.1.133.33517 > 192.36.148.17.53: 18768
> [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.237837 ens18 Out IP 192.168.1.133.43646 > 156.154.100.20.53:
> 28883 [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.259888 ens18 Out IP 192.168.1.133.51762 > 59.160.103.171.53:
> 46716 [1au] DNSKEY? incometax.gov.in. (57)
> 18:47:25.597312 ens18 In  IP 192.168.1.162.53963 > 192.168.1.133.53: 23+
> ? eportal.incometax.gov.in. (42)
> 18:47:26.498891 ens18 Out IP 192.168.1.133.52631 > 125.16.225.122.53:
> 12762 [1au] DNSKEY? incometax.gov.in. (57)
>
> I feel this is something related to DNS RRKEY Record size?
>
> Plus then I dumbdb on my server and went through cache using command
> *#rndc dumpdb -all*
>
> And here is the output
>
> incometax.gov.in.   3422NS  ns01.incometax.gov.in.
> 3422NS  ns02.incometax.gov.in.
> ns01.incometax.gov.in.  131 \-  ;-$NXRRSET
> ; ns01.incometax.gov.in. RRSIG NSEC ...
> ; ns01.incometax.gov.in. NSEC ns02.incometax.gov.in. A RRSIG NSEC
> ; incometax.gov.in. SOA ns01.incometax.gov.in.
> ns-admin.cpc.incometax.gov.in. 2023060970 7200 3600 1209600 3600
> ; incometax.gov.in. RRSIG SOA ...
> ns02.incometax.gov.in.  120 \-  ;-$NXRRSET
> ; ns02.incometax.gov.in. RRSIG NSEC ...
> ; ns02.incometax.gov.in. NSEC ns03.incometax.gov.in. A RRSIG NSEC
> ; incometax.gov.in. SOA ns02.incometax.gov.in.
> ns-admin.cpc.incometax.gov.in. 2023071447 7200 3600 1209600 3600
> ; incometax.gov.in. RRSIG SOA ...
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 131] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 120] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 130] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 119] [v4 unexpected] [v6 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 117] [v4 unexpected] [v6 nx

Re: Recursive client query rate-limiting

[Greg Choules via bind-users]

Hi Ben.
In short, kinda. "recursive-clients" limits the overall number of
concurrent recursive queries the server will handle.
For each of those queries there is also "clients-per-query", which limits
the number of different sources all asking the same question at the same
time. This is so that, for popular domains, BIND only has to get an answer
once, for all clients who want it.

There is no such thing though as per-client query rate limiting. However,
there is response rate limiting, configured with "rate-limit", which (as
the name implies) limits the rate at which a given client will be sent
responses.

It's all in the ARM :) https://bind9.readthedocs.io/en/latest/index.html
Cheers, Greg

On Wed, 30 Aug 2023 at 18:42, Ben Bridges  wrote:

> Hi,
>
> Is there a BIND configuration option that would limit the number of
> recursive client buffers/structures that any single client can consume on a
> BIND server at a time?  I.e., any single client could only consume (say) 10
> recursive client buffers at a time, and if the client sends another
> (unique) recursive query while it is already consuming 10 recursive client
> buffers, the server would drop the new request (or send a SERVFAIL
> response).  I know about the Recursive Client Rate Limiting
> (fetches-per-server, fetches-per-zone) and clients-per-query, those aren't
> what I'm asking about.
>
> Thanks,
>
> .Ben Bridges.
> --
> 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: Is this KB example backwards? Re: Multiple master servers for the same zones

[Greg Choules via bind-users]

Hi Fred.
No, the sense is correct.
Imagine you have a server with a secondary zone of (say) "example.com",
which transfers data for that zone from a primary somewhere. The secondary
loads data received during a zone transfer straight into memory and uses it.
It is optional for the secondary to also write that data to a file on its
local storage, if you specify a "file" statement in the zone declaration.
Optional, but sometimes handy.

If the server currently being secondary for "example.com" does write that
zone to disc then it is easy to switch it to become primary because it
already has the zone file stored locally. Just change the "type", leave the
"file" statement alone and delete (or comment) the "primaries".

Does that help?
Greg

On Thu, 7 Sept 2023 at 19:31, Fred Morris  wrote:

> Re-reading the KB article referenced below...
>
> On Tue, 5 Sep 2023, Leroy Tennison via bind-users wrote:
> >
> > [...]  I'm assuming i can use
> > https://kb.isc.org/docs/managing-manual-multi-master to "demote" one of
> > them but is there anything to look for concerning possible
> > inconsistencies and how do I check for those issues?
>
> Second paragraph:
>
>In BIND 9, it is relatively simple to switch a server from secondary to
>primary in real time: if you store the data in a file, simply redefine
>the zone type and change type master; to type slave;.
>
> That seems to me to be saying secondary == master and primary == slave.
>
> There seems to be a mixing of metaphors here. I don't think combining the
> traditional and newspeak terminology contributes to clarity. In any case
> I'd rewrite this as:
>
>In BIND 9, it is relatively simple to switch a server from primary to
>secondary in real time: if you store the data in a file, simply redefine
>the zone type and change type primary; to type secondary;.
>
> --
>
> Fred Morris
> --
> 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: consolidating in-addr.arpa data

[Greg Choules via bind-users]

Hi John.
Can you tell me a bit more please?
- What zones exist in both BIND and MS DNS for something.10.in-addr.arpa?
- Where are hosts auto registering to? I'd guess MS, but it would be good
to confirm.
- What does fragmentation look like? A few real examples would be useful.
I'm trying to understand just what is the problem.
- How much of 10 do you use?
- What do you mean by "...can be published from two different DNS
services."? Could you expand on that please?
- Is there any zone transfer between BIND and MS DNS?

Thanks, Greg

On Fri, 15 Sept 2023 at 21:00, John Thurston 
wrote:

> This question involves making our BIND system work with Microsoft's DNS
> software. If this makes it off-topic, let me know and I'll be quiet about
> it.
>
> We use ISC BIND to hold and host most of our zone data. Internally, we
> have delegated some zones, and they are held in Microsoft DNS. These zones
> are used for MS Active Directory 'Domains', and accept auto-registration of
> DNS records from authorized hosts. Because we are using 10-dot addresses
> internally, the auto-registration by hosts causes fragmentation of the
> 10.in-addr.arpa zone data.
>
> I recall someone once offered a bit of code to mash this zone data back
> together, so the same information can be published from two different DNS
> services. I've hunted through this list's archive and have not found the
> reference. Before I go roll my own, can anyone point me at an existing
> solution?
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591john.thurs...@alaska.gov
> Department of Administration
> State of 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
>
-- 
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

[Greg Choules via bind-users]

Hi John.
Sorry if this sounds picky, but a dot out of place in this game is the
difference between success and crash-n-burn.

Please can you show me EXACTLY what ...10.in-addra.arpa zones you have in
both sets of DNS?

>From previous work with AD clients I think that, if it doesn't already
exist, MS DNS will auto-create the reverse zone with the class (remember
classes?) that matches the client's IP. e.g. if a client comes along saying
"I'm 10.1.2.3" then MS DNS will create the /8 or class A reverse zone
"10.in-addr.arpa". Not "3.2.1.10..." or "2.1.10..." or "1.10..." but the
whole of 10!
This is because (close your ears MS) it assumes it is the only DNS in town.
Why would there be another one? If there is one client with a 10.x.y.z
address then there are potentially several billion more, so we'll create
10... just to be on the safe side. This makes MS DNS THE source of truth
for all 10, so no-one else can have any of it unless you start creating
delegations. More on that in a bit.

So first things first, Is this what happens in your environment? Or
something else? Real examples please + screenshots from MS DNS of the list
of zones. Screenshots? In a mailing list?? Try it anyway. You can redact
hostnames if you like, though they won't mean anything out of context.

Secondly, why do you have ...10 in BIND at all? What's its purpose?

Next, I would keep it simple. Don't try and replicate data in different
places if you don't need to. You COULD use zone transfer, of course, which
brings me to my next point...

Decide on a policy and stick to it. What data do you want MS DNS to be
authoritative for, what data do you want BIND to be authoritative for and
where do users send their queries?
For example, if AD clients are all assigned addresses from the range 10.1
then MS DNS only needs a zone 1.10..., not 10... The automatic zone
creation behaviour can be overridden if you create the zones you need at
the start.

In a previous life, I wanted ALL clients to query BIND and for MS to be
just a database. BIND would be authoritative for 10, MS would be
authoritative for (say) 1.10 and 2.10 but NOT 10. BIND would be
authoritative for 10 and delegate 1.10 and 2.10 to MS. ALL clients would
query BIND, including when performing their dynamic updates to MS. This
works because BIND knows who is responsible for all addresses starting 10.1
or 10.2

Long-winded, I know. But I think it's important to understand your end goal
before configuration.

Cheers, Greg

On Sat, 16 Sept 2023 at 01:16, John Thurston 
wrote:

> A host which auto-registers in MS DNS, creates an A in foo.alaska.gov and
> PTR in whatever.10.in-addr.arpa. MS DNS is happy to publish those.
>
> But the DNS system running on BIND also has a whatever.10.in-addr.arpa
> zone.
>
> So if I want to find the PTR for 13.12.11.10.in-addr.arpa, I must query
> both DNS systems in turn. If I get NXDOMAIN from both, then I can say the
> PTR doesn't exist.
>
> On each system, I'd like to be able to take the 10.in-addr.arpa data from
> the other, compute the differences, and incorporate them locally. Then I'll
> be able to query either system, and accept an NXDOMAIN with confidence.
>
> And since writing my earlier note, I have re-located the code I think I
> stumbled across earlier
>
> Tony Finch's "nsdiff"
>
>
> https://dotat.at/prog/nsdiff/
>
>
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
>
> On 9/15/2023 2:21 PM, Greg Choules wrote:
>
> Hi John.
> Can you tell me a bit more please?
> - What zones exist in both BIND and MS DNS for something.10.in-addr.arpa?
> - Where are hosts auto registering to? I'd guess MS, but it would be good
> to confirm.
> - What does fragmentation look like? A few real examples would be useful.
> I'm trying to understand just what is the problem.
> - How much of 10 do you use?
> - What do you mean by "...can be published from two different DNS
> services."? Could you expand on that please?
> - Is there any zone transfer between BIND and MS DNS?
>
> Thanks, Greg
>
> On Fri, 15 Sept 2023 at 21:00, John Thurston 
> wrote:
>
>> This question involves making our BIND system work with Microsoft's DNS
>> software. If this makes it off-topic, let me know and I'll be quiet about
>> it.
>>
>> We use ISC BIND to hold and host most of our zone data. Internally, we
>> have delegated some zones, and they are held in Microsoft DNS. These zones
>> are used for MS Active Directory 'Domains', and accept auto-registration of
>> DNS records from authorized hosts. Because we are using 1

Re: consolidating in-addr.arpa data

[Greg Choules via bind-users]

Hi.
Although it is technically possible to do reverses on non-octet boundaries
(for example, see https://www.ietf.org/rfc/rfc2317.txt) it is a
complete pita, in my experience. Personally I would not head down that
path. Stick to /8, /16 or /24.

Cheers, Greg

On Sat, 16 Sept 2023 at 09:20, G.W. Haywood via bind-users <
bind-users@lists.isc.org> wrote:

> Hi there,
>
> On Sat, 16 Sep 2023, John Thurston wrote:
>
> > A host which auto-registers in MS DNS, creates an A in foo.alaska.gov
> > and PTR in whatever.10.in-addr.arpa. MS DNS is happy to publish those.
> >
> > But the DNS system running on BIND also has a whatever.10.in-addr.arpa
> > zone.
> >
> > So if I want to find the PTR for 13.12.11.10.in-addr.arpa, I must query
> > both DNS systems in turn. If I get NXDOMAIN from both, then I can say
> > the PTR doesn't exist.
> >
> > On each system, I'd like to be able to take the 10.in-addr.arpa data
> > from the other, compute the differences, and incorporate them locally.
> > Then I'll be able to query either system, and accept an NXDOMAIN with
> > confidence.
>
> Is there a reason not to split the /8 into two /9s or something like that?
> Then you'd have no fragmentation (at least not for this reason) and you'd
> always know who to ask.
>
> > And since writing my earlier note, I have re-located the code I think I
> > stumbled across earlier
> >
> > Tony Finch's "nsdiff"
>
> Does that mean problem replaced, if not solved?
>
> --
>
> 73,
> Ged.
> --
> 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: consolidating in-addr.arpa data

[Greg Choules via bind-users]

>From the correct mail alias!

On Sat, 16 Sept 2023 at 21:50, Greg Choules 
wrote:

> Hi Ged.
> 172.16/12 is not a special case. The whole problem (IMHO) stems from how
> humans have chosen to represent both IP addresses (v4; v6 are different and
> actually a little easier) AND DNS domain names; both using the dot
> character (or full stop or period or whatever it's called in your
> geography) as a separator.
>
> Say a user is assigned the address 172.16.1.2 and you want to create a PTR
> record for that. According to
> https://datatracker.ietf.org/doc/html/rfc1034#section-5.2.1 point 2:
> >The octets of the IP address are reversed, used as name components, and
> suffixed with "IN-ADDR.ARPA".
>
> This designates ARPA as a top level domain and IN-ADDR as a second level
> domain
> What this means in practice is that the first octet of an IPv4 address
> (172 in this example) is a third level domain then there is a dot, which
> not only indicates the transition from octet 1 to octet 2 but also the
> transition from a third level domain to a fourth level domain.
> Thus it is that octets and domains are inextricably linked.
>
> There are a couple of ways you could handle reverses for 172,16/12
> addresses, depending on your addressing scheme, desired flexibility in DNS
> and business policy.
>
> I would like to offer an opinion at this point: only create zones if you
> need them!
> For instance, if one group of people run a single DNS technology, go for
> the most general domains you can get away with.
>
> Using 172.16/12 address space as an example you could create up to sixteen
> zones as follows:
> 16.172.in-addr.arpa
> 17.172.in-addr.arpa
> ...
> 31.172.in-addr.arpa
>
> You may not need all of them.
> PTR records in these zones would look like:
> 2.1   PTR   the-first-client.example.com.
> etc.
>
> You might be tempted to create zones like the following:
> 1.16.172.in-addr.arpa
> 2.16.172.in-addr.arpa
> ...
>
> The PTR record in the first zone for 172.16.1.2 would look like:
> 2   PTR   the-first-client.example.com.
>
> It's a personal choice. But I would keep the zones to a minimum.
>
> For 10.whatever addresses you have even more choices:
> 1) 10.in-addr.arpa
> 2) 1.10.in-addr.arpa (and possibly 2.10.. 3.10.. etc.)
> 3) 1.1.10.in-addr.arpa (and 2.1.10.. 3.1.10.. etc. etc.)
>
> With 1) you need one zone.
> With 2) you need up to 256 zones.
> With 3) you need up to 64k zones.
>
>
> John's issue (I think) is that two sets of people using different
> technologies both want a piece of the 10 pie. So it doesn't make sense that
> both of them have the whole /8. He needs to make a decision about which DNS
> is higher in the pecking order. Personally I would make it BIND.
> For instance, if you use 10.1 in MS land but 10.2, 10.3 and others for
> non-MS purposes:
>
> In MS DNS, configure 1.10.in-addr.arpa as a zone, making sure that the
> automatically created 10.in-addr.arpa gets deleted. All MS clients that
> want to register their 10.1.x.y addresses will submit a dynamic update to a
> DC, which will add it to this 1.10... zone.
>
> In BIND, configure 10.in-addr.arpa as a zone. In that zone add the
> following:
> 1  NS  ms-dns1.active-directory-domain.
> 1  NS  ms-dns2.active-directory-domain.
> ...
> Thus, 10.1 has been delegated to the MS boxes and 10.everything else stays
> with BIND.
>
>
> As a parting shot, IPv6 is a bit more granular; see
> https://datatracker.ietf.org/doc/html/rfc8501
> Since IPv6 addresses are written as hextets separated by colons there is
> no implicit connection with DNS domains. 8501 says that each hex character
> (4 bits) is to be treated as a separate DNS label. This has the potential
> to make the number of zones incredibly huge. The upside is that each level
> in the domain hierarchy now only represents 4 bits rather than 8, so it is
> more granular.
>
> That's me done for the night. I hope some of that makes sense.
> Cheers, Greg
>
> On Sat, 16 Sept 2023 at 10:23, G.W. Haywood via bind-users <
> bind-users@lists.isc.org> wrote:
>
>> Hi there,
>>
>> On Sat, 16 Sep 2023, Greg Choules wrote:
>> > On Sat, 16 Sep 2023,  G.W. Haywood wrote:
>> > ...
>> > > Is there a reason not to split the /8 into two /9s or something like
>> that?
>> > ...
>> > Although it is technically possible to do reverses on non-octet
>> boundaries
>> > (for example, see https://www.ietf.org/rfc/rfc2317.txt) it is a
>> > complete pita, in my experience. Personally I would not head down that
>> > path. Stick to /8, /16 or /24.
>>
>> Please could you elaborate