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

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

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: [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=true=Yang=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287=395096713%40qq.com=>
>  
> 
> 
> -- 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=true=Yang=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287=395096713%40qq.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: 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 
> 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 
> 
> It looks like +https was added in version 9.17 I just need to get RedHat 
> to start using it
> 
> RW
> From: bind-users  > 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>>
> Cc: ond...@isc.org   >; 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 
> 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: Access denied Bind9

[Greg Choules via bind-users]

Hi Ritah.

I think rndc is a red herring. Whether you can control your server using
rndc or not is a different topic to "why am I seeing  'denied'" in the
logs.

I think a couple of questions you need to ask yourself are:

   Should these servers be receiving recursive queries from anywhere?
  If no, then named.conf should contain "recursion no;" and settings
such as "allow-query-cache" should be set to "none;".
  If yes, then define the set of clients you expect them to receive
queries from, create some ACLs, set "recursion yes;" and
"allow-query-cache" (at a minimum) to use the ACLs.

   What zones are these servers authoritative for?
  If the server are not supposed to be receiving recursive queries and
the queries you see in your log are not ones for which you are
authoritative then take notes about which clients are sending these queries
and go on a hunt. Perhaps the clients are misconfigured, or just being
'playful'!

Some useful reading might be these articles and others in the KB.
https://kb.isc.org/docs/bind-best-practices-authoritative
https://kb.isc.org/docs/bind-best-practices-recursive

and of course the ARM.
I hope that helps.

Cheers, Greg

On Tue, 8 Mar 2022 at 01:45, Ritah Mulinde  wrote:

> Hi Guys
> Just got my primary and secondary name servers  running.
>
> However, when i reload rdnc and tail the syslogs all i get is "(
> .xx.com): query (cache) '.xx.com/A/IN' denied"
>
> Not sure why.
>
> kindly asking for some pointers on where to start looking
>
>
> Thank you
> --
> 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: Forwarding zone, setup

[Greg Choules via bind-users]

Sending from the correct email alias this time!

On Thu, 3 Mar 2022 at 09:53, Greg Choules 
wrote:

> Hi Greg.
> Basically, you can't forward out of authority. If server A is
> authoritative for "example.com" it is authoritative for that and
> everything below that, ad infinitum, unless you tell it otherwise.
> There is an implicit hierarchy as to how queries are dealt with. It arises
> because BIND can be both recursive AND authoritative simultaneously, so
> there has to be some way to choose how to go about responding to incoming
> queries. Using dynamic routeing as an analogy, it's a bit like BGP needing
> to choose which is the best prefix by running through its decision
> algorithm.
> In BIND, authority trumps all; there is nothing higher. Next comes
> forwarding.
>
> BIND isn't the only DNS server software that does this, by the way.
> Microsoft's AD DNS role does too because it can be both recursive and
> authoritative simultaneously.
>
> As already mentioned, the trick (if this is really what you need to do in
> the first place) is to 'give away' the slice of your namespace that you
> want to forward. i.e. to convince the server it is not authoritative for it
> anymore. Hence you need to delegate (say) "notmine.example.com" by adding
> some (or even one) NS records for it in "example.com". The slight
> headspin is, it doesn't matter what those NS records are because they will
> never be used. It is the act of delegation that is the important thing, not
> where it is delegated to.
>
> What I used to do was add (e.g.) "notmine   NS   x." and then create the
> forward zone (or in MS speak, Conditional Forwarder). As long as, having
> created the delegation, the only choice the server now has is to forward
> that name, life is good. Therefore you MUST also have "forward only". The
> server must not be allowed to try and recurse, or it would then need to
> resolve "x.", which will fail.
>
> However, having said all this, if you know what are the names and
> addresses of the MS DNS server hosting "ab.somedomain.local" (i'll keep it
> zipped on the use of .local - Microsoft!), why not just delegate to them
> directly? Then you don't need a forward zone at all. I have found from
> bitter experience that forwarding, although (usually) easy to get working
> can lead you into a warren of problems down the line. So I tended to avoid
> it wherever possible.
>
> I hope that helps.
> Greg
>
> On Tue, 1 Mar 2022 at 18:53, Gregory Sloop  wrote:
>
>> >Are you loading the parent domain and trying to zone forward a child
>> domain on the same DNS server? I.e. loading somedomain.local and trying to
>> forward ab.somedomain.local
>>
>>
>>
>> Yup, exactly.
>>
>>
>>
>> That solution was suggested by Jeff Sumner yesterday, but it seemed a
>> little nuts to me (BIND behaving that way) - though your explanation makes
>> that behavior seem less crazy.
>>
>> If I get a chance, I'll perhaps try that, just to see if it fixes it -
>> though someone at ISC might save me the work, confirming the behavior.
>> (please do!)
>>
>>
>>
>> And, if that's the case, then static-sub is the far superior option -
>> since it's much more simple and straight-forward.
>>
>>
>>
>> Consider it solved.
>>
>> If ISC can confirm that behavior for forwarding a child domain when the
>> server is also auth for the parent zone, that would be very nice!
>>
>>
>>
>> Thanks to everyone, again, for the help!
>>
>>
>>
>>
>>
>>
>> Are you loading the parent domain and trying to zone forward a child
>> domain on the same DNS server? I.e. loading somedomain.local and trying to
>> forward ab.somedomain.local
>>
>> If so an NS delegation is required in every instance I have done in my
>> environment. The NS doesn't need to be "right" but it needs to exist. I
>> don't know the internal BIND logic for that but I have always taken it as
>> "I load the parent and I know the child doesn't exist because there isn't a
>> delegation to make it exist so why would I forward something that doesn't
>> exist".
>>
>>
>> On Tue, Mar 1, 2022, 1:18 PM Gregory Sloop  wrote:
>>
>>> Static-sub fixes the issue.
>>>
>>>
>>>
>>> Any idea why static-sub works when forwarder doesn't?
>>>
>>>
>>>
>>> (Again, the server is using recursion. Dig queries return the RA flag,
>>> so I know it's actually offering recursion in reality.)
>>>
>>>
>&

Re: Bind: Standard Ports And Non Standard Ports

[Greg Choules via bind-users]

Take 2. Sent from the wrong email address!

Greg

On Sat, 12 Feb 2022 at 08:01, Greg Choules 
wrote:

> > "...to use a traditional VPN solution such as DNSSEC ..."
> DNSSEC is not a VPN service. It is regular, unencrypted DNS on port 53, or
> whichever port you choose - see the manuals and KB articles for how to
> configure non-standard ports. DNSSEC adds extra records to provide checks
> that answers are genuine.
>
> > "P.S. My guess is that this so-call "security" service is no such thing,
> or at
>   least its not the only thing.  They are probably harvesting DNS
> lookups
>   to sell as marketing data, or at least that would be my first guess."
> I would try to establish exactly what Comcast's Security Service is
> actually doing first, or if this is even the real problem. Run some manual
> tests between the machines inside and the machines outside to establish
> whether port number is the problem. e.g. use "dig -p"
>
> Thanks, Greg
>
>
> On Fri, 11 Feb 2022 at 16:30, Jakob Bohm via bind-users <
> bind-users@lists.isc.org> wrote:
>
>> On 2022-02-11 16:20, Tim Daneliuk via bind-users wrote:
>> >
>> > After some months of poking around, we are now certain that our
>> > so-called "Business"
>> > service from Comcast is compromising our DNS servers because of their
>> > execrable "Security Edge" garbage.  (They are willing to remove this
>> > 'service'
>> > only if we are willing to incur a higher monthly recurring fee.)
>> >
>> > Our master is in the wild and works fine, but the slave is behind the
>> > compromised
>> > Comcast pipe.  The effect of having Security Edge in place is that the
>> > slave cannot get updates from the master and is also unable to resolve
>> > anything outside our own zone.   Comcast is apparently hijacking all
>> port
>> > 53 requests and doing unspeakable things with them.
>> >
>> > Is there a way to have these servers work as usual, listening to
>> > resolution
>> > request on port 53, but have the slave update AND forward requests to
>> the
>> > master over a non-standard port, so as to work around the Comcast
>> > madness?
>> >
>> > TIA,
>> > Tim
>> >
>> > P.S. My guess is that this so-call "security" service is no such
>> > thing, or at
>> >  least its not the only thing.  They are probably harvesting DNS
>> > lookups
>> >  to sell as marketing data, or at least that would be my first
>> guess.
>> If bind cannot be configured to avoid a port blocking or filtering 3rd
>> party filter between two of your own servers, the obvioussolution is
>> to use a traditional VPN solution such as DNSSEC or OpenVPN to encrypt
>> all traffic between the two servers.  That should pass through any ISP
>> filters that don't block work-from-home VPNs.
>>
>> Enjoy
>>
>> Jakob
>> --
>> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
>> This public discussion message is non-binding and may contain errors.
>> WiseMo - Remote Service Management for PCs, Phones and Embedded
>>
>> --
>> 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.
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]

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 10-dot addresses
>> internally, the auto-registration by hosts causes fragmentation of the

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 a bit?
>>
>&g

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 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 128] [v4 unexpected] [v6 nxrrset]
> ; ns02.incometax.gov.in [v6 TTL 117] [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 nxrrset]
> ; ns01.incometax.gov.in [v6 TTL 128] 

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: 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: How should I configure internal and external DNS servers

[Greg Choules via bind-users]

Hi Nick.
First question, does the internal zone *have* to keep the same name? As has
been said already, this is a fairly common setup done by people a long time
ago who usually didn't think through the consequences of their actions.
What follows assumes you could change the name of the internal zone.

What would be better (IMHO) is for you to keep "example.com" as your
external zone in an external (hopefully in a DMZ) primary server, serving
the world with public addresses they need to reach, and internally create a
new zone - "internal.example.com" (maybe also other "somethingX.example.com"
too) as your internal zone in an internal primary server for serving
internal clients with the addresses they need.

Internal clients send recursive queries (RD bit set to 1, hence why
recursion needs to be enabled) to an internal server, if you can separate
the functions physically: this server is a resolver (aka cache) because of
that.
That resolver *could* get its internal data from a separate, internal
primary server in a number of ways - stub, static-stub, secondary or
forward zones. I won't go into the differences right now.
The internal primary server just sits there and provides answers for
internal names. It would probably not need to have recursion enabled,

If you only have a single box internally (though I'd recommend at least
two, for resilience) they can be both resolver *and* authoritative in the
same box. You don't need views. In this case the primary zone is defined on
this box rather than on a different box. If you have another one and want
it to behave identically it could be a secondary server to this primary

If the resolver receives queries for non-internal names -
e.g.public.example.com, www.facebook.com or anything else, they won't match
the internal zone and thus they are candidates for external resolution. It
could contact the outside world in a number of ways, such as by direct
recursion, forwarding to your own forwarder in a DMZ (which then does the
recursion) or forwarding to a public service such as Google (others exist).

The principle is that the internal zone(s) is a subdomain of the external
zone and hence more specific: a bit like adding host routes in a router.
Anything that is not in "internal.example.com" the resolver deals with as
if it were anything else in the world. That includes anything in "
example.com", for which it queries the external primary server, just like
anyone else in the world would.

The external primary server does not need recursion enabled because queries
it receives (from resolvers) will have the RD bit set to 0.

One other thing you ought to do in the external primary server, in the zone
"example.com", is to delegate "internal.example.com" to your internal
authoritative servers. This doesn't suddenly mean that the world can make
queries for "name.internal.example.com" because they won't be able to reach
your internal servers to get queries to them. Even if they could, an answer
like 10.10.10.10 would be meaningless.

The reason for the delegation is DNSSEC. If you enable DNSSEC validation on
your resolver, which is a good idea, it would work fine for the rest of the
world. But to validate internal names it needs to be able to follow the
path to the internal authoritative servers, all the way down from the root.
So it needs "example.com" to tell it where "internal.example.com" lives,
then the chain is complete. This is a bit simplistic, but that's the
general idea.

If you cannot change the internal zone name and it *must* stay the same as
the external zone name, life gets a little more complicated but it's still
workable.

Internally you would have to split DNS functions into two sets of servers -
recursive and authoritative. These could be different views on the same
boxes, but that starts getting tricky and I would recommend separate IP
addresses for each function if that's the path you have to take.

The general principle is still the same: internal names are more specific
subdomains of the external zone. But in this case each internal name would
need to be its own zone (stub, static-stub etc.) and the resolver would
need to be told how to obtain answers for these zones. The vital point is
that you *must not* configure the zone "example.com" internally because
that will obscure the external version completely. Zones like "
internal-www.example.com", "internal-mail.example.com" and what have you
are fine because they are more specific than the general "example.com",
queries for which will just fall through to the outide world along with any
other name.

That was a bit of an essay, but I hope at least some of it made sense.

Cheers, Greg

On Fri, 3 Nov 2023 at 16:33, Nick Howitt via bind-users <
bind-users@lists.isc.org> wrote:

> Hmm, I'll admit to only skim reading it but is seems quite complicated
> for what I was hoping for. It would be trivial if I could change the
> bind-internal machine to using dnsmasq (ugh!). Then the bind-internal
> machine would 

Re: Forwarders working differently on bind9.8 & bind9.11

[Greg Choules via bind-users]

Hi Prashasti.
I'm on my phone, so I'll keep it brief.
- ditch both 9.8 and 9.11; install 9.18
- why are you forwarding to yourself? 127.0.0.1
- get binary packet captures and look at them in Wireshark to see what's
actually going on.
- real IPs please.
- why use "port xxx"?

Cheers, Greg

On Tue, 19 Sep 2023, 12:28 Prashasti Arora, 
wrote:

> I have configured a new zone to forward certain queries to my application
> on 2 VMs (One local and the other in my network) through a specific port. I
> have 2 similar setups - they are identical, except that one uses bind9.8
> and the other uses bind9.11. Configuration is also identical for both.
>
> On the first setup (using bind9.8): the traffic I send gets distributed
> uniformly.
> On the second setup (using bind9.11): the traffic gets distributed barely.
> 99% of the traffic is sent to one VM.
>
> I have verified that forwarding is working correctly on both, the issue is
> not with the application because both VMs on each setup can handle traffic
> individually, the firewall is not blocking the queries, and the
> configuration is correct.
>
> This is the zone:
>
> zone "example.com" IN {
> type forward;
> forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
> forward only;
> };
>
>
> Please share any other possible solutions.
> --
> 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: Bind failures following update/reboot w/ 9.18.1

[Greg Choules via bind-users]

Your MTU is not the point. It's what happens beyond your equipment that may
have a bearing. However, as I said, I don't think IP fragmentation will be
your problem in this case, so that's a whole other discussion for a
different day.
pcaps are your friend though. From a packet capture you can see exactly
what happened on the wire, rather than speculate.

Cheers, Greg

On Fri, 13 May 2022 at 18:00, Philip Prindeville <
philipp_s...@redfish-solutions.com> wrote:

> My MTU is 1500 bytes, so I don't think that's the problem.
>
> But UDP can fragment via IP...
>
>
> > On May 13, 2022, at 10:34 AM, Greg Choules <
> gregchoules+bindus...@googlemail.com> wrote:
> >
> > Hi Philip.
> > Can you run packet captures? I'm running 9.18.0 (close enough?) in
> Docker and just traced what happens going from "dnssec-validation no;" to
> "dnssec-validation auto;" It makes a DNSKEY query for "." to one of the
> roots. The response size was over 900 bytes, so depending on what UDP
> payload size is advertised there might need to be some retrying over TCP.
> But you'll only know whether that is happening from a pcap.
> > So I'd say.. check EDNS payload size, check what your firewall(s) is/are
> prepared to let through, check whether DNS/TCP is allowed at all, check if
> something is doing IP fragmentation (though I wouldn't expect this to come
> into play with a packet ~1k).
> >
> > I hope some of that is useful.
> > Cheers, Greg
> >
> > On Fri, 13 May 2022 at 17:07, Philip Prindeville <
> philipp_s...@redfish-solutions.com> wrote:
> > After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started
> seeing a lot of:
> >
> >
> > May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid
> signature found
> > May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid
> signature found
> > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> './NS/IN': 192.203.230.10#53
> > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> 'net/DS/IN': 8.8.4.4#53
> > May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid
> signature found
> > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> 'com/DS/IN': 8.8.4.4#53
> > May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid
> signature found
> > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> 'net/DS/IN': 66.232.64.10#53
> > May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid
> signature found
> > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> 'com/DS/IN': 66.232.64.10#53
> >
> >
> > In my options, I had:
> >
> > dnssec-validation auto;
> >
> > But had to turn this off.  It had been working.  This is a production
> firewall/router.
> >
> > What troubleshooting should I do to fix this?
> >
> > I had tried:
> >
> > rndc managed-keys refresh
> > rndc managed-keys sync
> >
> > But don't understand why that would have been necessary unless the root
> keys got updated recently.
> >
> > Scrolling to the very top of the logs I see:
> >
> > May 12 19:24:04 OpenWrt named[11061]: managed-keys-zone: Unable to fetch
> DNSKEY set '.': timed out
> >
> > Thanks,
> >
> > -Philip
> >
> >
> > --
> > 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 failures following update/reboot w/ 9.18.1

[Greg Choules via bind-users]

Hi Philip.
Can you run packet captures? I'm running 9.18.0 (close enough?) in Docker
and just traced what happens going from "dnssec-validation no;" to
"dnssec-validation auto;" It makes a DNSKEY query for "." to one of the
roots. The response size was over 900 bytes, so depending on what UDP
payload size is advertised there might need to be some retrying over TCP.
But you'll only know whether that is happening from a pcap.
So I'd say.. check EDNS payload size, check what your firewall(s) is/are
prepared to let through, check whether DNS/TCP is allowed at all, check if
something is doing IP fragmentation (though I wouldn't expect this to come
into play with a packet ~1k).

I hope some of that is useful.
Cheers, Greg

On Fri, 13 May 2022 at 17:07, Philip Prindeville <
philipp_s...@redfish-solutions.com> wrote:

> After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started
> seeing a lot of:
>
>
> May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid signature
> found
> May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid
> signature found
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving './NS/IN':
> 192.203.230.10#53
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> 'net/DS/IN': 8.8.4.4#53
> May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid
> signature found
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> 'com/DS/IN': 8.8.4.4#53
> May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid
> signature found
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> 'net/DS/IN': 66.232.64.10#53
> May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid
> signature found
> May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving
> 'com/DS/IN': 66.232.64.10#53
>
>
> In my options, I had:
>
> dnssec-validation auto;
>
> But had to turn this off.  It had been working.  This is a production
> firewall/router.
>
> What troubleshooting should I do to fix this?
>
> I had tried:
>
> rndc managed-keys refresh
> rndc managed-keys sync
>
> But don't understand why that would have been necessary unless the root
> keys got updated recently.
>
> Scrolling to the very top of the logs I see:
>
> May 12 19:24:04 OpenWrt named[11061]: managed-keys-zone: Unable to fetch
> DNSKEY set '.': timed out
>
> Thanks,
>
> -Philip
>
>
> --
> 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

Fwd: Request to use "Canonical/Mirror"

[Greg Choules via bind-users]

Hi Felicia.
As the previous responder said, don't think of entire servers being one or
the other, it's individual zones.

IMHO the terms "primary" and "secondary" are just as meaningful as the
terms "master" and "slave", but without the emotional and historical
baggage. You just have to give yourself time to get used to them.

Cheers, Greg

On Sat, 14 May 2022 at 00:11, Felicia P  wrote:

> Hello, I see that ISC updated terminology for BIND9 to use
> primary/secondary in addition to the original master/slave which many
> projects have been deprecating.
>
> In the context of BIND9, it seems that 'primary/secondary' is less clear
> than master/slave.
>
> My understanding is that it is possible to have a standalone BIND server
> that is running as a 'master' yet acting as a 'secondary' for a
> particular domain.  In this context, secondary doesn't necessarily refer
> to the 'slave' status of the server, but that it is sort of like a
> backup server in the event that the primary is unavailable.
>
> Given this, it seems like instead of 'primary/secondary', a better
> choice of terms would be 'canonical/mirror' which unambiguously conveys
> the roles of respective servers and does not overlap with other contexts
> or meanings of primary/secondary.
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: 9.18 behavior change for mDNS queries with dig

[Greg Choules via bind-users]

Hi Larry.
sudo tcpdump -ni any -c 1000 -w .pcap port 5353

For  I usually include the date, hostname and some other
meaningful stuff to help you remember what it was for in 6 months' time.
Whilst this is running, make some queries in another terminal window.

I hope this helps.
Cheers, Greg

On Mon, 27 Jun 2022 at 14:11, Larry Stone 
wrote:

> Petr, you are going to have to tell me how to create an appropriate PCAP
> file. As most of this stuff works so well these days, it’s been years since
> I had to do any sort of packet level analysis (moved on to other things
> professionally) and what I knew of how to do that has long since been lost.
> My issue is on a small home network so very little goes wrong. The
> appropriate tcpdump command to get what is needed should be all I need.
>
> --
> Larry Stone
> lston...@stonejongleux.com
>
>
>
>
>
> > On Jun 27, 2022, at 1:48 AM, Petr Špaček  wrote:
> >
> > On 27. 06. 22 8:26, Evan Hunt wrote:
> >> On Sun, Jun 26, 2022 at 10:00:08PM -0500, Larry Stone wrote:
> >>> I recently moved from 9.16 to 9.18 and just noticed that dig no longer
> >>> resolves mDNS queries.
> >>>
> >>> With 9.16:
> >>> dig +short @224.0.0.251 -p 5353 hostname.local
> >>> 192.168.0.82
> >>>
> >>> With 9.18:
> >>> dig +short @224.0.0.251 -p 5353 hostname.local
> >>> ;; connection timed out; no servers could be reached
> >>>
> >>> I can’t find anything in the Release Notes (or anyplace else) about
> this.
> >> "dig" was rewritten in 9.18 to use the libuv-based network manager
> >> instead of the old socket code; it's probably related to that. Please
> >> open a bug report at https://gitlab.isc.org/isc-projects/bind9/-/issues
> ,
> >> we'll look into it.
> >
> > Please don't forget to attach PCAP file produced by tcpdump or similar
> tool so we can see if anything happens on the wire or not.
> >
> > --
> > Petr Špaček
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: 9.18 behavior change for mDNS queries with dig

[Greg Choules via bind-users]

Wireshark works just fine on a Mac (I am using it right now) and yes, it is
a great tool. You also have the choice of using tcpdump in a terminal
window, if that's your preference. Personally I usually capture using
tcpdump and view later in Wireshark.

On Fri, 1 Jul 2022 at 12:01, Petr Menšík  wrote:

> Wireshark is a great tool with a nice GUI, which can record you traffic
> on selected ports. Just use capture filter port 5353. But I am not
> certain it works on Mac just as it does not Linux.
>
> On 6/27/22 15:10, Larry Stone wrote:
> > Petr, you are going to have to tell me how to create an appropriate PCAP
> file. As most of this stuff works so well these days, it’s been years since
> I had to do any sort of packet level analysis (moved on to other things
> professionally) and what I knew of how to do that has long since been lost.
> My issue is on a small home network so very little goes wrong. The
> appropriate tcpdump command to get what is needed should be all I need.
> >
>
> --
> 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: Can't modify an existing SPF record

[Greg Choules via bind-users]

The SPF record type was deprecated in 2014 and the SPF definition string
*must* now be contained as data in a TXT record.
BIND will still load a zone containing SPF records, but it will check
whether a TXT record also exists that contains the same string and will
generate a log message telling you if it doesn't find one.

>From a quick glance at the webmin manual it *should* allow you to put
anything you like in a TXT record.
@Roberto Carna   your SPF record currently looks
like this:

company.com. 971 IN TXT "v=spf1 mx ip4:[corpIP] include:mktomail.com ~all"


The ip4:[corpIP] will not work. [] are not valid characters in the SPF
specification and in any case ip4: must be followed by a literal dotted
decimal IPv4 address.

On Fri, 8 Jul 2022 at 17:34, Benny Pedersen  wrote:

> On 2022-07-08 18:14, Crist Clark wrote:
> > As far as BIND is concerned, this is arbitrary text in a TXT record.
> > It doesn’t know or care about SPF syntax within it.
>
> TXT records is mostly used, and SPF records is in bind supported
> --
> 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: Can't modify an existing SPF record

[Greg Choules via bind-users]

Hi Roberto. What domain is this SPF for and exactly how are you trying to
add the extra term?
Cheers, Greg

On Fri, 8 Jul 2022 at 16:38, Roberto Carna  wrote:

> Dear, from my webmin interface for BIND9, I try to add an additional
> allowed sender host to our SPF record, but I get the following error:
>
> Failed to save record : 'relay.company.com' is not a valid host to
> allow sending from
>
> What does this mean? Do I have to consider some important thing I'm
> forgetting ?
>
> relay.company.com is already defined in our public DNS, and it has a
> reverse record too.
>
> if I add this record by hand, it's not replicated to the DNS slaves.
>
> Thanks in advance!!!
> --
> 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: Basic setup instructions

[Greg Choules via bind-users]

Hi Gene.
Please can you post a link to 'the website' you refer to?
Where have you got to so far? BIND requires one config file - named.conf -
which, at its simplest, doesn't need to contain much at all; the defaults
should pretty much just work. But let's start with what you have now and,
if possible, any error messages you see when trying to start it.

Greg

On Mon, 25 Jul 2022 at 15:19, Gene Ammerman via bind-users <
bind-users@lists.isc.org> wrote:

> So I have tried this even with macOS to even 12.4. But I am still not able
> to get DNS setup on my machine using the instructions from the web site. Is
> there any other instructions to follow?
>
>
> Respectfully,
>
> Gene Ammerman
> Apple Support Senior Advisor
> Business & Education
>
> > On Jul 25, 2022, at 8:11 AM, Ondřej Surý  wrote:
> >
> > macOS 10.10 reach end-of-life 5 years ago. You can try installing recent
> enough compiler with C11/C17 support and up-to-date libraries, but you are
> mostly on your own.
> >
> > Ondřej
> > --
> > Ondřej Surý — ISC (He/Him)
> >
> > My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
> >
> >> On 25. 7. 2022, at 16:02, Gene Ammerman via bind-users <
> bind-users@lists.isc.org> wrote:
> >>
> >> Is there a more basic setup instruction guide than what is provided on
> the web site?
> >>
> >> I am on a Mac running macOS 10.10 with server 5.7 and I just need to
> setup DNS for this.
> >>
> >> Thank you
> >>
> >>
> >> Respectfully,
> >>
> >> Gene Ammerman
> >> Apple Support Senior Advisor
> >> Business & Education
> >>
> >> --
> >> 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: success resolving xxx after disabling EDNS

[Greg Choules via bind-users]

Hi Veronique.
Every DNS server should support EDNS by now. It has been around for a very
long time. Even if it doesn't support EDNS it should ignore it.

I made some test queries and packet captures to 23.82.12.28. Whatever this
box is, please talk to the manufacturer about EDNS support.
Or.. it may be that some network infrastructure - firewalls are usually the
first place to look - is blocking this traffic.

Whatever is happening at the authoritative end, it needs to be fixed. All
modern recursive servers will use EDNS.

Cheers, Greg

On Wed, 4 May 2022 at 13:13, Veronique Lefebure 
wrote:

> Hello,
>
> If we see this on our DNS server logs (BIND 9.11):
>
> 04-May-2022 12:55:37.675 edns-disabled: info: success resolving '
> sour.woinsta.com/A' (in 'woinsta.com'?) after disabling EDNS
>
> - are we correct to say that with BIND 9.16, that query wil always fail
> because EDNS won't be disabled anymore ?
> - is there any tuning that needs to be done ?
> - with BIND 9.11: how many times does BIND try before disabling EDNS ?
> from what we can see in the logs, BIND seems to first try all NS and as
> they all fail, then it disable EDNS and then retries. Is it correct ?
>
> Thanks,
> Veronique
> --
> 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: DNS traffic tracking

[Greg Choules via bind-users]

Hi Alex.
Your use case may be very different to the one I faced in my previous job.
But there we did not and could not charge for DNS. It was seen as a
necessary but free resource.
If you *really* want to account for how many queries clients are making,
a quick and dirty solution is enabling querylog, BUT be warned it causes a
lot more load on the system. The better tool would be DNStap.

But there is no 1-to-1 correlation between user queries (client side of
server) and fetches (Internet side of server).
In a perfect (i.e. lab) setup, if all clients make the same query then,
apart from the initial fetches to find the answer(s) the server can answer
everything from cache and there is no internet traffic at all. (100% cache
hit ratio)
The other extreme is clients all making random queries (PRSD), which your
server cannot cache, so this causes it to generate much more Internet
traffic; at least as much as the clients are generating. (0% cache hit
ratio)

Cheers, Greg



On Fri, 6 May 2022 at 16:02, Alex K  wrote:

> Hi all,
>
> I have the following problem: I run a caching dns server using bind9
> v9.10.3 in a gateway device which it serves several internal LAN IP
> addresses (clients). I am doing some traffic accounting in the gateway
> device using Linux conntrack so as to calculate the generated client
> traffic (mostly HTTP/HTTPs related, in/out) so as to charge the volume
> consumed.
>
> What I cannot charge is the actual DNS traffic that each client is
> generating, since each client DNS request is actually two sessions, one
> between client and gateway device and the other between gateway and
> upstream DNS servers. It seems to me not fare to charge the traffic
> observed between the client and the gateway since the internal DNS traffic
> includes cached responses and may be much higher from the actual DNS
> traffic observed on the WAN side (gateway - upstream).
>
> I was wondering if there is a solution to this. If bind9 has any feature
> that can be used to track the WAN DNS traffic and understand from which
> client was first requested/generated. In this way I will be able to
> differentiate the DNS traffic per client and avoid accounting DNS traffic
> that the gateway generated for its own services.
>
> Just as an additional note on this, I had in the past the same issue with
> the proxy traffic that this same gateway was generating and found a
> solution by using TPROXY feature of the squid proxy, which exposes the real
> internal client IP address at the WAN traffic which can later be NATed.
>
> Thanx for any ideas,
> Alex
> --
> 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.11/RHEL7 Server Freezes FUTEX_WAKE_PRIVATE

[Greg Choules via bind-users]

Hi Peter.
Off the top of my head, could it be this?

random-device

The source of entropy to be used by the server. Entropy is primarily needed
for DNSSEC operations, such as TKEY transactions and dynamic update of
signed zones. This options specifies the device (or file) from which to
read entropy. If this is a file, operations re- quiring entropy will fail
when the file has been exhausted. If not specified, the default value
is /dev/random
(or equivalent) when present, and none otherwise. The random- device option
takes effect during the initial configuration load at server startup time
and is ignored on subsequent reloads.

BIND will need a good source of randomness for crypto operations.

Cheers, Greg

On Mon, 1 Aug 2022 at 23:08, White, Peter 
wrote:

> I’m running BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.9 (Extended Support
> Version) on RHEL 7 in a chroot jail.
>
>
>
> As of late, at times running some rndc commands are causing my server to
> lock up. It’s usually an “rndc addzone” that triggers the issue. I’ll also
> mention that I have recently started signing some domains with DNSSEC, so I
> suspect it may be somehow related.
>
>
>
> Here is an example of a command that frequently triggers my issue,
> although it doesn’t trigger it every time.
>
>
>
> rndc addzone '"example.com" in external {type master; file "dnssec/
> example.com";key-directory "keys"; auto-dnssec maintain; inline-signing
> yes;};'
>
>
>
> During these times, named will not respond to any rndc commands, nothing
> is logged to the bind logs (I’m running trace level 3 ), and will not
> answer queries. Everything seems just frozen in time. Waiting for a period
> of time, varying from a few seconds to many minutes, the server picks back
> up again and operates normally. The following are my observations to this
> point.
>
>
>
> CPU and memory show as being fine.
>
>
>
> top - 17:57:37 up 33 min,  3 users,  load average: 0.00, 0.01, 0.05
>
> Tasks:* 125 *total,   *2 *running,* 123 *sleeping,   *0 *stopped,   *0 *
> zombie
>
> %Cpu(s):  *0.2 *us,  *0.3 *sy,  *0.0 *ni,* 98.5 *id,  *0.0 *wa,  *0.0 *hi,
> *0.0 *si,  *1.0 *s
>
> KiB Mem :  *1842956 *total,   *439452 *free,   *665760 *used,   *737744 *
> buff/cache
>
> KiB Swap:  *8384508 *total,  *8384508 *free,*0 *used.  *1013652 *avail
> Mem
>
>
>
> Strace shows the following over and over again.
>
>
>
> strace -p 1156 -f
>
>
>
> [pid  1159] futex(0x7fc1c15a307c,
> FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 16657, {tv_sec=1659390139,
> tv_nsec=25586}, 0x) = -1 ETIMEDOUT (Connection timed out)
>
>
>
> Any pointers here would be greatly appreciated. I’m about at my wits end
> with this one, and rebuilding this server on a newer build of RHEL or
> recompiling BIND is not a journey that I would like to take at the moment.
> --
> 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: Question regarding newsyslog.conf and Bind logs

[Greg Choules via bind-users]

Hello J
What is it you're actually trying to achieve here?

Cheers, Greg

On Thu, 25 Aug 2022 at 04:24, J Doe  wrote:

> Hello,
>
> I was wondering if anyone could provide feedback on whether the
> following: newsyslog.conf file is correct to allow for daily log
> rotation for my Bind 9.16.30 logs ?
>
> My currently logging settings in: named.conf are:
>
>  ...
>  logging {
>  channel chn_file_queries {
>  buffered no;
>  file "/var/queries.log"
>  versions 2 size 1g suffix increment;
>  print-category yes;
>  print-severity yes;
>  print-time yes;
>  severity info;
>  };
>  ...
>  };
>  ...
>
> newsyslog.conf examples tend to make use of: pkill but I note in the
> Bind ARM and man page that signals are deprecated in favor of: rndc.
>
> I am *thinking* the following should work for newsyslog.conf
>
> /var/named/var/queries.log6407 *$D0  Z
> "/usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true"
>
> So settings:
>
>  Log path: My Bind is running in chroot
>  File mode:0640
>  Log count:7 (1 per day)
>  Size limit:   none
>  Frequency:$D0 (daily)
>  Flags:z to compress
>  Binary:   rndc (instead of pkill)
>
> Is this correct ?
>
> Thank you,
>
> - J
> --
> 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: Zone transfer over VPN

[Greg Choules via bind-users]

Hi Michael.
Have you tried without the "allow-transfer" statements at all? I find it
usually works best to start simple, get it working, then apply security bit
by bit.
Do you have logs from all servers? What are they telling you specifically
about what is the issue?
Lastly, get packet captures of port 53. Evidence is always handy to see
what is actually going on, rather than guessing what you *think* should be
going on.

Cheers, Greg

On Tue, 6 Sept 2022 at 23:16, Michael De Roover  wrote:

> Hello everyone,
>
> I have currently 2 internal networks under my control, both of which have
> BIND
> name servers in them. The "main" network uses the 192.168.10.0/24 subnet,
> while the "satellite" network uses the 192.168.20.0/24 subnet. Following
> this,
> I will refer to these as main and satellite. You may consider the
> satellite
> network sort of like a road warrior setup, though both are fully-fledged
> networks with hosts in them.
>
> The main network has a set of two gateways with IP addresses
> 192.168.10.51,
> and 192.168.10.52. They perform VRRP to each other, with floating IP
> 192.168.10.9. Both of them make a VPN connection to two VPS's using
> WireGuard.
>
> The VPS's have IP ranges 10.8.2.0/24 and 10.8.3.0/24 respectively. Pretty
> much
> all traffic that's relevant here (AXFR/IXFR on TCP 53) goes through the
> former.
>
> The satellite network does the same thing, it also connects to the VPS's
> but
> does not perform VRRP with another node. The gateway on the satellite
> network
> uses IP address 192.168.20.1.
>
> The name servers on these networks are 192.168.10.4, 192.168.10.5 and
> 192.168.10.6 on the main network, and 192.168.20.3 on the satellite
> network.
>
> This is running on BIND 9.16.25 for Alpine on the main network, and BIND
> 9.11.5-P4-5.1+deb10u7-Debian for Debian on the satellite network. All of
> them
> are running in LXC with bridged networking.
>
> Now I would like to get both of these networks to share their local zones.
> So
> in the name servers' configs I would initially declare an ACL for this and
> add
> that to the zone entries, on the main network. This worked fine for those,
> being in the same subnet. But once I tried to do the same on the satellite
> network, BIND on the main network would see the zone transfer as coming
> from
> 192.168.10.51 or 192.168.10.52 -- instead of coming from 192.168.20.3 --
> and
> refuse it. The same is true the other way around, where the name server on
> the
> satellite network sees zone transfers from the main network as coming from
> 192.168.20.1 instead.
>
> In other words, only the first hop (or the last, depending on how you look
> at
> it) is being considered, with zone transfers seemingly being expected to
> occur
> from within the same subnet. Surely I'm not the only one who dealt with
> this?
> If anything, I consider myself still a newbie. Is it possible to get BIND
> to
> consider the original source of the zone transfer instead?
>
> For now I have added an "external" ACL to these networks, and made the
> respective local zones authorized to transfer from this ACL, which has the
> gateways of their local networks in there. However, this means that
> anything
> on the main network can transfer from the satellite network, and anything
> from
> the satellite network can transfer from the main network. After all, the
> name
> servers have no way to tell where it's really coming from. While
> everything on
> these networks is owned or otherwise controlled to a reasonable extent by
> me,
> I don't like this. In my book, this is a security issue. I think I need a
> better solution for this.
>
> Configuration-wise, this would be a snippet from ns1.lan on the main
> network
> with the relevant bits.
>
> acl external {
>admin;
>192.168.10.9;
>192.168.10.51;
>192.168.10.52;
> };
> ; ...
> zone "lan" {
>type master;
>file "/etc/bind/zones/fwd.lan.db";
>allow-transfer { internal; external; };
> };
> zone "10.168.192.in-addr.arpa" {
>type master;
>file "/etc/bind/zones/rev.lan.db";
>allow-transfer { internal; external; };
> };
>
> The satellite network's name server has a similar configuration to this,
> but
> the other way around.
>
> I have skimmed over these articles so far, but couldn't find anything
> relevant
> in them.
> - https://kb.isc.org/docs/aa-00726
> - https://www.zytrax.com/books/dns/ch7/xfer.html
>
> Thank you so much for taking your time to read this, and thanks in advance
> for
> any insights.
>
> --
> Met vriendelijke groet / Best regards,
> Michael De Roover
>
>
> --
> 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 

Re: address/prefix length mismatch

[Greg Choules via bind-users]

Hi Elias.
I can't say why this might have worked with 9.11 (if it did - I'd be
surprised). But you should not/cannot define ACLs like this:
10.60.0.1/23;
/23 means consider only the first 23 bits of the available 32 bits of an
IPv4 address and ignore the rest (in this context. Please don't someone
else shoot me down for other uses of netmasks).

Since the human-readable version of an IPv4 address (in bits) is 8.8.8.8
(no, not THAT 8.8.8.8) a /23 mask means care about the first three octets
(24 bits), except the last bit of the third octet (back to 23 bits), and
don't care about the fourth octet at all.

So in this case the third octet *must* be an even number (zero is even in
this context) and the fourth octet should be zero. Like this:
10.60.0.0/23;

10.60.2.0/23; would also be acceptable.
10.60.17.0/23; would not be acceptable because the third octet is odd, so
its low order bit is 1.

I hope that helps.
Greg



On Wed, 24 Aug 2022 at 13:17, Elias Pereira  wrote:

> Oh, sorry... :D
>
> here it is
>
> # cat named.conf.local
> # ACL das redes internas
> # Ultima modificação: 24/08/2022
>
> acl "internal" {
> 10.60.0.1/23;
> 10.10.1.1/24;
> 10.10.2.1/25;
> 10.10.3.1/25;
> 10.10.4.1/25;
> 10.10.5.1/25;
> 10.51.0.1/23;
> 10.10.6.1/25;
> 10.10.7.1/26;
> 172.20.0.1/26;
> 10.50.0.1/23;
> 10.40.0.1/22;
> 10.56.0.1/22;
> };
>
> On Wed, Aug 24, 2022 at 9:14 AM Anand Buddhdev  wrote:
>
>> On 24/08/2022 14:08, Elias Pereira wrote:
>>
>> Hi Elias,
>>
>> > I upgraded my AD, debian 10 to 11 and bind upgraded to version 9.16.27.
>> >
>> > Now I get the address/prefix length mismatch error in name.conf.local.
>> >
>> > In my first AD that I have not upgraded yet, it is working correctly
>> with
>> > the same settings in version 9.11.x.
>> >
>> > What is the problem with version 9.16.x?
>>
>> We don't know what your named.conf.local looks like, so it's impossible
>> to help you. Please help yourself by asking a better question, in which
>> you show your configuration. Then someone can probably spot the error
>> and provide a helpful answer.
>>
>> Regards,
>> Anand
>>
>
>
> --
> Elias Pereira
> --
> 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: Question regarding newsyslog.conf and Bind logs

[Greg Choules via bind-users]

Hi again J.
If I understand correctly, you want to enable querylog on a busy recursive
server permanently, rotate the files once a day and don't care if you lose
some logs because the number of queries on a busy day generates more data
than the specified log file is allowed to contain.

My question has to be, why?

Firstly, querylog is not an efficient way to record information about what
your clients are doing, dnstap is far more efficient if you want a record
of some or all information about queries and/or their responses. If using
files to retain this information, the rotation choices are the same as for
channels. If your server is only handling a few 10s or 100s QPS, querylog
will do. But if it's handling 1000s times more than that you will cause it
unnecessary extra stress and dnstap is your friend.

Secondly, if you insist on using querylog (actually, this also applies to
dnstap), why not just leave named to rotate the files based on size and
number, allowing for the set of files to be easily large enough to contain
(say) a week's worth of data. Then you could run a cron job to grep today's
logs and do what you want with them. You don't have to worry about other
processes sending commands to named to cause something to happen, it just
gets on with it.

/soapbox.

On Thu, 25 Aug 2022 at 22:08, J Doe  wrote:

> On 2022-08-25 16:46, Richard T.A. Neal wrote:
>
> > Hi J,
> >
> > I'm coming a little late to the party on this one and I think you might
> struggle to do rotation based on both date/time *and* file size, but I use
> logrotate to rotate all of my BIND logs daily, keeping 31 days of logs. And
> you'll see that one of the last things that logrotate does is to call [rndc
> reconfig] which causes BIND to generate fresh log files in place of the
> rotated ones.
> >
> > My BIND logging itself is setup based largely on the configuration
> described here:
> > https://kb.isc.org/docs/aa-01526
> >
> > My logrotate.conf file then looks like this the following, which itself
> is based on this:
> > https://ixnfo.com/en/logrotate-bind9.html
> >
> > #-
> > # RTAN BIND 9 daily log rotation
> > #
> > # Note that the log file won't rotate until at least one day AFTER you
> set this for the first time.
> > # Eg if you create this file on a Wednesday then they won't rotate for
> the first time until THURSDAY night:
> > #
> https://serverfault.com/questions/375004/logrotate-not-rotating-the-logs
> > #-
> >
> > /var/log/named/*.log
> > {
> >olddir /var/log/named/archived
> >compress
> >create 0644 bind bind
> >daily
> >dateext
> >missingok
> >notifempty
> >rotate 31
> >sharedscripts
> >postrotate
> >  /usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true
> >endscript
> > }
> > #-
> >
> > Best,
> > Richard.
>
> Hi Richard,
>
> Thank you for your reply.  I am not attempting to configure the server
> so that rotation is based on size *and* time.  The size configuration in
> the logging stanza was more to put an upper limit on a log *before* it
> is rotated.  I could drop the parts that mention 2 versions and
> incrementing the filename and just keep: size 1G.
>
> Let's say it's an extremely busy day and my Bind recursive resolver logs
> are getting really big.  I want the maximum size a day's logs can be
> *before* they are compressed to be 1G.  I am aware that if the server is
> still under heavy load that queries past that point will not be logged.
>
> Then, at the end of the day, newsyslog compresses the logs and rotates
> them so that I keep 7 days worth of compressed logs.
>
> The logrotate your example uses looks good, but I'm on a very minimal
> OpenBSD 7.1 host.  I could add the logrotate package, but newsyslog is
> in the base system and I already use it for doing the same kind of log
> rotation for my firewall logs, so I was hoping to stick to newsyslog.
>
> The postrotate directive in the logrotate example you sent me was what I
> was basing my newsyslog config on, as it uses rndc and not pkill SIGHUP.
>
> I am assuming it would work with newsyslog, or am I incorrect about that ?
>
> Thanks again,
>
> - J
> --
> 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: address/prefix length mismatch

[Greg Choules via bind-users]

Hi Sten.
That is absolutely what you do *not* want to do.

Writing it out in binary might help. /23 means the following:
  1110 

'1' bits mean, test an incoming address against the corresponding bit from
the address in the mask.
'0' bits mean, don't test an incoming address against the corresponding bit
from the address in the mask.

The ACL 10.60.0.0/23 will match *any* address from 10.60.0.0 to 10.60.1.255
*inclusive*.

There is no concept of network address and broadcast address here. It is
just pattern matching.

Cheers, Greg

On Wed, 24 Aug 2022 at 15:40, Sten Carlsen  wrote:

> I think you want something like this:
>
> (!10.60.0.0; !10.60.0.255; 10.60.0.0/24)
>
> First deny the two addresses you want not to be part of the *ACL* and
> then accept the whole network.
>
> First match is used, so 10.60.0.0 would match !10.60.0.0 and be rejected
> before the next  are tested.
>
> Thanks
>
> Sten
>
> On 24 Aug 2022, at 16.05, Ondřej Surý  wrote:
>
>
> On 24. 8. 2022, at 15:58, Elias Pereira  wrote:
>
> hello Ondrej,
>
> Not completely wrong, because 255 is the broadcast.
>
>
> No, it's not. This is ACL specification, not a interface/network
> configuration.
>
> For a better understanding, then it would be Available range 10.60.0.1 to
> 10.60.1.254.
>
>
> No, I've already provided you with a correct answer what 10.60.0.0/23
> means in terms of range, why do you insist on this?
>
> Correctly specified range (without address/host bits) does takes the whole
>> range.
>
>
> Like this 10.60/23; ?
>
>
> I think others have already answered that, I would be just repeating their
> answers.
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
>
> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý  wrote:
>
>>
>>
>> On 24. 8. 2022, at 15:26, Elias Pereira  wrote:
>>
>> 
>> Hello Greg,
>>
>> Why doesn't bind work with networks/subnets in the conventional way?
>>
>>
>> It does.
>>
>> If the private subnet is 10.60.0.0/23, then it means that the address
>> range is 10.60.0.1 to 10.60.1.254.
>>
>>
>> That’s wrong. 10.60.0.0/23 means 10.60.0.0 to 10.60.1.255 range.
>>
>> How do I configure this ACL in named.conf.local so that it takes the
>> whole range?
>>
>>
>> Correctly specified range (without address/host bits) does takes the
>> whole range.
>>
>> Ondrej
>> --
>> Ondřej Surý — ISC (He/Him)
>>
>> My working hours and your working hours may be different. Please do not
>> feel obligated to reply outside your normal working hours.
>>
>> On Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev  wrote:
>>
>>> On 24/08/2022 14:16, Elias Pereira wrote:
>>>
>>> Hi Elias,
>>>
>>> > Oh, sorry... :D
>>> >
>>> > here it is
>>> >
>>> > # cat named.conf.local
>>> > # ACL das redes internas
>>> > # Ultima modificação: 24/08/2022
>>> >
>>> > acl "internal" {
>>> > 10.60.0.1/23;
>>>
>>> This is the issue. The address part of the prefix should be the lowest
>>> address in that prefix. If you change this to 10.60.0.0/23, it will be
>>> fine. The same goes for all the other prefixes in your list. Change the
>>> 1's to 0's.
>>>
>>> > 10.10.1.1/24;
>>> > 10.10.2.1/25;
>>> > 10.10.3.1/25;
>>> > 10.10.4.1/25;
>>> > 10.10.5.1/25;
>>> > 10.51.0.1/23;
>>> > 10.10.6.1/25;
>>> > 10.10.7.1/26;
>>> > 172.20.0.1/26;
>>> > 10.50.0.1/23;
>>> > 10.40.0.1/22;
>>> > 10.56.0.1/22;
>>> > };
>>>
>>
>>
>> --
>> Elias Pereira
>> --
>> 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
>>
>>
>
> --
> Elias Pereira
>
>
> --
> 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: Proxy requests but filter out IPv4 address

[Greg Choules via bind-users]

Hi Matthias.
In DNS there are many record types. For IP addresses there are two types: A
for IPv4 addresses and  for IPv6 addresses. If your client asks for the
 record it should get only IPv6 addresses. So what is your client
asking for?
Can you show us a real example where both IPv4 and IPv6 addresses are being
returned? pcap would be best.

Cheers, Greg

On Fri, 19 Aug 2022 at 07:56, Matthias Fechner  wrote:

> Dear all,
>
> I'm not sure if bind can do this, but let me explain what I would like
> to do.
>
> It is a hostname from a foreign domain, like:
> test.myfritz.net
>
> it is returning an IPv4 and IPv6 address:
> host test.myfritz.net
> test.myfritz.net has address 100.91.114.161
> test.myfritz.net has IPv6 address 2a02:6d40:17:9dc7:e228:6dff:fe8d:1f41
>
> The IPv4 address will not work due to carrier-nat, so only the IPv6
> address would be reachable from outside.
>
> Is there a way to configure bind that if I resolve test.myfritz.net (it
> must not be under the domain myfritz.net, but can also be in a way
> aliased to a domain I own) that it only returns the IPv6 address but
> totally skip the IPv4 address?
> The IPv4 and IPv6 addresses are not permanent and change at least once a
> day.
>
>
> Gruß
> Matthias
>
> --
>
> "Programming today is a race between software engineers striving to
> build bigger and better idiot-proof programs, and the universe trying to
> produce bigger and better idiots. So far, the universe is winning." --
> Rich Cook
>
> --
> 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: dig +norecurse behaviour changed with 9.16.33

[Greg Choules via bind-users]

Hi Veronique.
As other people have said, more details please.

To have a complete picture of what is going on, not only would we need to
know what your dig tests look like, but also where dig is sending its
queries and how that DNS server is configured.

You can tell dig to send queries anywhere, using @. However, if you
don't use that it will default to using the nameservers in
/etc/resolv.conf. So it may be useful to see the contents of that.

Wherever dig is sending its queries, we would need to know what that server
will do with them. So its configuration would also be useful.

Lastly, the best way to see queries and responses, right down to the nuts
and bolts, is with a packet capture.

You thought this was an easy question, huh ;)

Can you provide at least some of these things, to get started?

Cheers, Greg

On Wed, 26 Oct 2022 at 16:41, Veronique Lefebure 
wrote:

> Hi,
>
> dig answer is different between BIND 9.11 and BIND 9.16(.33) when
> +norecurse option is used.
> Is this documented somewhere ?
>
> Is there an option that needs to be set so that the behaviour of 9.16 is
> the same as the one in 9.11.
>
> The change is that with 9.16, if the requested name is a CNAME, only the
> CNAME value is returned by dig, while with 9.11 dig would return both the
> CNAME value and the IP of the CNAME.
>
> Thanks,
> Veronique
> --
> 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: dig +norecurse behaviour changed with 9.16.33

[Greg Choules via bind-users]

Hi Veronique.
As Petr said, please don't send a pcap. This is getting beyond the scope of
the list and into proper support territory. For which I would recommend
that CERN pay ISC for professional support services.

Regarding your external example, I get this:
%dig @192.65.187.5 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

ip-dns-0.cern.ch. 900 IN A 137.138.28.176
; <<>> DiG 9.18.5 <<>> @137.138.28.176 foundservices.cern.ch
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Both queries and responses are different from the ones in your mails and
the response I receive for "foundservices.cern.ch" from ext-dns-1 contains
only 1 answer, regardless of whether recursion (which the server doesn't
accept) is requested or not.

In short, this example does not help to explain what you are seeing.
Greg

On Thu, 27 Oct 2022 at 13:28, Veronique Lefebure 
wrote:

> Well,
>
> So here a bit more details.
> Sorry, I cannot take an example with a DNS server accessible to you (*)
> because they have all been upgraded to 9.16.
>
> The .cern.ch contains:
>
> spectrum-lb IN NS ip-dns-1.cern.ch.
> spectrum-lb IN NS ip-dns-2.cern.ch.
> spectrum IN CNAME spectrum-lb.cern.ch.
>
> and
>
> spectrum-lb.cern.ch contains:
>
> $ORIGIN .
> $TTL 60 ; 1 minute
> spectrum-lb.cern.ch IN SOA ip-dns-1.cern.ch. internal-dns.cern.ch. (
> 273 ; serial
> 3600 ; refresh (1 hour)
> 300 ; retry (5 minutes)
> 360 ; expire (5 weeks 6 days 16 hours)
> 60 ; minimum (1 minute)
> )
> NS ip-dns-1.cern.ch.
> NS ip-dns-2.cern.ch.
> A xxx.xxx.xx.140
>
>
>
> named configuration file is identical between 9.11 and 9.16 except for the
> following options that we have added for 9.16:
>
> #BIND916 options
> qname-minimization disabled;
> stale-answer-enable no;
> stale-refresh-time 0; #default is 30
> max-stale-ttl 1w;
> dnssec-policy none;
> synth-from-dnssec no;
> min-cache-ttl 0;
> min-ncache-ttl 0;
> minimal-responses no;
>
>
>
>
>
> (*) On an external DNS server you can try with the following similar case:
>
> Running DiG 9.11.21 on a linux client
>
> ext-dns-1 (192.65.187.5) runs BIND9.16:
>
> dig @ext-dns-1 foundservices.cern.ch | grep flags | grep ANSWER
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> dig @ext-dns-1 foundservices.cern.ch *+norecurse* | grep flags | grep
> ANSWER
> ;; flags: qr aa ra; QUERY: 1, ANSWER: *1*, AUTHORITY: 0, ADDITIONAL: 1
>
>
> Full output:
>
> dig @192.65.187.5 foundservices.cern.ch +norecurse
> ; <<>> DiG 9.11.21 <<>> @192.65.187.5 foundservices.cern.ch +norecurse
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9899
> ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 8786b980a1a80a790100635a7898a512a21aa6138faf (good)
> ;; QUESTION SECTION:
> ;foundservices.cern.ch. IN A
> ;; ANSWER SECTION:
> foundservices.cern.ch. 900 IN CNAME db-lb-1234.cern.ch.
> ;; Query time: 2 msec
> ;; SERVER: 192.65.187.5#53(192.65.187.5)
> ;; WHEN: Thu Oct 27 14:24:56 CEST 2022
> ;; MSG SIZE rcvd: 103
>
>
> ip-dns-0 runs BIND9.11:
>
> dig @ip-dns-0 foundservices.cern.ch | grep flags | grep ANSWER
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4
>
> dig @ip-dns-0 foundservices.cern.ch *+norecurse* | grep flags | grep
> ANSWER
> ;; flags: qr aa; QUERY: 1, ANSWER: *2*, AUTHORITY: 2, ADDITIONAL: 4
>
>
> Does that help ?
>
> Greg, can I send you a pcap file in a private email ?
>
>
> Thanks,
> Veronique
>
> On 27/10/2022 10:09 Greg Choules 
> wrote:
>
>
> Hi Veronique.
> No, we cannot easily reproduce this behaviour because we have no knowledge
> of the configs of either of those servers, the details of the zones you
> have configured, the contents of those zones or of the system on which you
> are running the dig command.
>
> As I said, we need to see everything please:
> - Full digs, not +short
> - you have specified @ip-dns0 and @ip-dns1 - the full configs of both of
> those servers please, including zone definitions and contents for where "
> spectrum.cern.ch" lives as it is not a name that can be resolved from the
> public Internet
> - a binary pcap file, using the -w option of tcpdump, capturing all port
> 53 traffic (UDP and TCP) between this machine and both DNS servers.
>
> By the way, when using the @ option of dig please use explicit IP
> addresses, not names. If

Re: dig +norecurse behaviour changed with 9.16.33

[Greg Choules via bind-users]

Hi Veronique.
No, we cannot easily reproduce this behaviour because we have no knowledge
of the configs of either of those servers, the details of the zones you
have configured, the contents of those zones or of the system on which you
are running the dig command.

As I said, we need to see everything please:
- Full digs, not +short
- you have specified @ip-dns0 and @ip-dns1 - the full configs of both of
those servers please, including zone definitions and contents for where "
spectrum.cern.ch" lives as it is not a name that can be resolved from the
public Internet
- a binary pcap file, using the -w option of tcpdump, capturing all port 53
traffic (UDP and TCP) between this machine and both DNS servers.

By the way, when using the @ option of dig please use explicit IP
addresses, not names. If you use a name, then dig first has to resolve that
name and the place it will go to do that is resolv.conf. So it is now
dependent on your system DNS setup to get an IP address to send the dig to.
Also, you have specified @ not @. This suggests to
me that in resolv.conf you have a 'search' list. Personally I don't like
search lists because they potentially increase the workload of the DNS
system generally, lengthen query times and mean that you can't be sure
exactly where an answer came from.

Thanks, Greg


On Thu, 27 Oct 2022 at 08:08, Veronique Lefebure 
wrote:

> Hi all,
>
> yes, here is a concrete example:
>
> # ip-dns-1 runs BIND 9.16.33:
>
> dig @ip-dns-1 spectrum.cern.ch +short +norecurse
> spectrum-lb.cern.ch. <- Here we get only the CNAME
>
> # ip-dns-0 runs BIND 9.11:
>
> dig @ip-dns-0 spectrum.cern.ch +short +norecurse
> spectrum-lb.cern.ch.
> xxx.xxx.xx.140 < Here we get in addition the IP of
> spectrum-lb.cern.ch.
>
>
> And yes, a capture shows confirms indeed that dig returns less information
> when the BIND 9.16.33 DNS server is used.
>
> I guess you can easily reproduce that behaviour, unless it is due to a
> mis-configuration bit on our DNS server ?
>
> Thanks,
> Véronique
>
> On 26/10/2022 21:04 Greg Choules 
> wrote:
>
>
> Hi Veronique.
> As other people have said, more details please.
>
> To have a complete picture of what is going on, not only would we need to
> know what your dig tests look like, but also where dig is sending its
> queries and how that DNS server is configured.
>
> You can tell dig to send queries anywhere, using @. However, if
> you don't use that it will default to using the nameservers in
> /etc/resolv.conf. So it may be useful to see the contents of that.
>
> Wherever dig is sending its queries, we would need to know what that
> server will do with them. So its configuration would also be useful.
>
> Lastly, the best way to see queries and responses, right down to the nuts
> and bolts, is with a packet capture.
>
> You thought this was an easy question, huh ;)
>
> Can you provide at least some of these things, to get started?
>
> Cheers, Greg
>
> On Wed, 26 Oct 2022 at 16:41, Veronique Lefebure <
> veronique.lefeb...@cern.ch> wrote:
>
> Hi,
>
> dig answer is different between BIND 9.11 and BIND 9.16(.33) when
> +norecurse option is used.
> Is this documented somewhere ?
>
> Is there an option that needs to be set so that the behaviour of 9.16 is
> the same as the one in 9.11.
>
> The change is that with 9.16, if the requested name is a CNAME, only the
> CNAME value is returned by dig, while with 9.11 dig would return both the
> CNAME value and the IP of the CNAME.
>
> Thanks,
> Veronique
> --
> 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: CVE-2022-2795

[Greg Choules via bind-users]

Hi Greg.
Short answer: no.
Slightly less short answer: no, if you prevent the server from trying to
follow delegations. It's that potentially wild goose chase that was the
problem.

In short:
- Forwarding must cover everything the server needs to do (that isn't
locally defined) i.e. global forwarding.
- Along with "forwarders {x;y;z;};" also configure "forward only;" to tell
the server not to chase down delegations, should forwarding fail for some
reason.
 If it's *only* forwarding it won't need to try and follow any NS records
it might receive; goose chase avoided.

Hope that helps.
Greg

On Tue, 18 Oct 2022 at 19:46, Greg Rabil  wrote:

> 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
>
-- 
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: Seeing lots of DNS issues on OpenWRT

[Greg Choules via bind-users]

Hi Philip.
I echo Fred's response; why forward?
- Backup your config
- remove/comment the "forwarders {}" statement
- start a tcpdump to disc for port 53 (for evidence about what happens next)
- stop/start 'named'.
- try queries/look in the log/stop the tcpdump and analyse it in Wireshark.

As an aside, you don't need zone "." for either of two reasons:
1) If you're global forwarding the hint zone will never get used anyway.
2) If you're not forwarding, BIND has the list of root servers built in, so
defining a hint zone yourself is pointless, unless you deliberately want to
use a different set of roots (e.g. a private network, GRX or similar)

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

test - please ignore

[Greg Choules via bind-users]

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: Dig -x +trace?

[Greg Choules via bind-users]

Hi Mike.
OK, let's try and do some practical things here.

Firstly, please share your /etc/resolv.conf
Secondly, please have two windows on the go. In the first, run "tcpdump
-nvi all -w  port 53". In the second, run your dig tests.
Then share your results. If you are reluctant to share *actually* what
happens it will, unfortunately, be very difficult to impossible to diagnose
exactly what's going on.

Does this help for starters?
Cheers, Greg



On Mon, 3 Oct 2022 at 21:08, Mike Hodson  wrote:

> On Mon, Oct 3, 2022 at 1:59 PM Ondřej Surý  wrote:
>
>>
>> > - If you are debugging an active issue with an externally published
>> domain, providing the full domain name allows others to query it in order
>> to help you. Omitting, changing, or obscuring the domain can make it harder
>> or impossible for others to help you.
>>
>> Anonymizing your question to the public open source list actually
>> prevents people from helping you, and is disrespectful because you are
>> asking for help for free but unwilling to contribute back at least with
>> real data.
>>
>
> I disagree. I believe it to be more disrespectful to demand that someone
> who cares about privacy, give the info that removes said privacy.
> I should have been very explicit in my question then:
>
> "Why does invoking dig multiple times return different results than
> expected"
>
> and the answer i got of:
>
>  'your version is buggy, get a proper version' seems to be the right
> answer to that.
>
> I'm still angry at ubuntu for pushing non-working software. I will take
> this up with them, if after I take the time to compile your current
> sources, I see significant improvement of my issue.
>
>
>> Also please tone down on the snarkiness. I get it that you might be
>> frustrated, but this mailing list is not a place to vent off your
>> frustration.
>>
> I'm more frustrated by the answer to "stop obfuscating so we can help" ; I
> did not initially ask the question "why is my delegation not working" i
> asked "why is dig not working".
>
> Mike
>
> --
> 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: Dig -x +trace?

[Greg Choules via bind-users]

Hi Mike.
No need to shoot. I missed your first message to the list.

Have you tried other popular open resolver services, to compare how they
each behave and see whether there are differences between them?
Or, since you have `dig` I'm guessing you probably also have BIND? If so,
have you tried using that?

Since you are unwilling to share a pcap I don't see what further help we
can be.
Good luck with Ubuntu and Cloudflare.

Greg

On Mon, 3 Oct 2022 at 21:55, Mike Hodson  wrote:

> On Mon, Oct 3, 2022 at 2:24 PM Greg Choules <
> gregchoules+bindus...@googlemail.com> wrote:
>
>> Hi Mike.
>> OK, let's try and do some practical things here.
>>
>> Firstly, please share your /etc/resolv.conf
>>
> nameserver 1.1.1.1
> as I said in my first message to the list.
>
>
>> Secondly, please have two windows on the go. In the first, run "tcpdump
>> -nvi all -w  port 53". In the second, run your dig tests.
>> Then share your results. If you are reluctant to share *actually* what
>> happens it will, unfortunately, be very difficult to impossible to diagnose
>> exactly what's going on.
>>
> I think this would be best left for Ubuntu's bug report, considering the
> new 9.18.7 source I found from ISC.org works properly, to completion, every
> time.
>
>
>
>> Does this help for starters?
>>
> Ubuntu not shipping broken software would help more.
>
>
>>
>>
>
>>
>>
>> On Mon, 3 Oct 2022 at 21:08, Mike Hodson  wrote:
>>
>>> On Mon, Oct 3, 2022 at 1:59 PM Ondřej Surý  wrote:
>>>
>>>>
>>>> > - If you are debugging an active issue with an externally published
>>>> domain, providing the full domain name allows others to query it in order
>>>> to help you. Omitting, changing, or obscuring the domain can make it harder
>>>> or impossible for others to help you.
>>>>
>>>> Anonymizing your question to the public open source list actually
>>>> prevents people from helping you, and is disrespectful because you are
>>>> asking for help for free but unwilling to contribute back at least with
>>>> real data.
>>>>
>>>
>>> I disagree. I believe it to be more disrespectful to demand that someone
>>> who cares about privacy, give the info that removes said privacy.
>>> I should have been very explicit in my question then:
>>>
>>> "Why does invoking dig multiple times return different results than
>>> expected"
>>>
>>> and the answer i got of:
>>>
>>>  'your version is buggy, get a proper version' seems to be the right
>>> answer to that.
>>>
>>> I'm still angry at ubuntu for pushing non-working software. I will take
>>> this up with them, if after I take the time to compile your current
>>> sources, I see significant improvement of my issue.
>>>
>>>
>>>> Also please tone down on the snarkiness. I get it that you might be
>>>> frustrated, but this mailing list is not a place to vent off your
>>>> frustration.
>>>>
>>> I'm more frustrated by the answer to "stop obfuscating so we can help" ;
>>> I did not initially ask the question "why is my delegation not working" i
>>> asked "why is dig not working".
>>>
>>> Mike
>>>
>>> --
>>> 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: Question About Internal Recursive Resolvers

[Greg Choules via bind-users]

Hi John.
Yes, you *could* forward and that was a setup I inherited a good few years
ago. The appeal is obvious: it's easy to do; just chuck queries over there
and get answers.
But forwarding keeps the RD bit set, meaning that the server being
forwarded to should a) have recursion enabled (though it will still answer
if it is authoritative anyway) and b) is now obliged to try and find an
answer, so if the people who run that server happen to configure forwarding
somewhere else you can potentially end up with long, ugly chains of
forwarding, even loops. None of stub, static-stub or mirror do this.

Just my 2p.
Greg

On Fri, 14 Oct 2022 at 17:38, JW λ John Woodworth  wrote:

> Hi Bob,
>
> I've been able to do this with 'forward' zones.  The config would go in
> the resolver but the files would not.
>
>
> /John
>
>  Original message 
> From: Bob McDonald 
>
> I'm thinking about redesigning an internal DNS environment. To begin
> with, all internal DNS zones would reside on non-recursive servers
> only. That said, all clients would connect to recursive resolvers.
>
> The question is this; do I use an internal root with pointers to the
> internal zones (as well as the outside DNS world) or do I include stub
> zones to point at the non-recursive internal servers?
>
> Access to the internal DNS zones would be controlled by location.
> (e.g. guest WiFi devices would NOT have access to internal DNS
> zones...)
>
> Recursive resolvers would allow implementation of features such as RPZ,
> etc.
>
> Regards,
>
> Bob
> --
> 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: Question About Internal Recursive Resolvers

[Greg Choules via bind-users]

Hi Bob.
In a previous life I did just this. Large resolvers for customers and
internal users, defaulting to the Internet but with specific configuration
to internal auth-only servers for private zones (I used stub but
static-stub and mirror are alternatives - they each behave slightly
differently). In my case these resolvers forwarded (only) to Internet-edge
resolvers, which then did recursion. There were no internal roots anywhere.
Essentially the idea was, treat internal resolution as specific exceptions
to the general rule of "everything lives in the Internet".

One note of caution is, beware DNSSEC validation. These days it is on by
default, which is not necessarily a problem, even if your internal zones
aren't signed. But what it does mean is that internal zones *must* be
properly delegated from parent zones in the Internet, otherwise the chain
of trust will be broken and validation will fail. e.g. if your registered
domain in the outside world is "example.com" then a valid internal zone
could be "internal.example.com".
You can configure BIND to *not* validate certain zones, which is a way
around it. But I'd recommend doing it right from the start, if you have the
option.

I hope that helps.
Greg

On Fri, 14 Oct 2022 at 17:08, Bob McDonald  wrote:

> I'm thinking about redesigning an internal DNS environment. To begin
> with, all internal DNS zones would reside on non-recursive servers
> only. That said, all clients would connect to recursive resolvers.
>
> The question is this; do I use an internal root with pointers to the
> internal zones (as well as the outside DNS world) or do I include stub
> zones to point at the non-recursive internal servers?
>
> Access to the internal DNS zones would be controlled by location.
> (e.g. guest WiFi devices would NOT have access to internal DNS
> zones...)
>
> Recursive resolvers would allow implementation of features such as RPZ,
> etc.
>
> Regards,
>
> Bob
> --
> 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: Question About Internal Recursive Resolvers

[Greg Choules via bind-users]

Hi Grant.
My understanding is this, which is almost identical to what I did in a
former life:

client ---recursive_query---> recursive_DNS_server
---non_recursive_query---> internal_auth/Internet

where:
client == laptop/phone/server running stub resolver code
recursive_DNS_server == what Bob is asking about, a recursive-only DNS
server
internal_auth == the other component, an authoritative-only DNS server

Separation of internal and external clients - preventing external ones from
accessing internal names - is easily achieved with a couple of views, such
as this:

view "external" {
match-clients { address_match_list }; # the set of all possible
addresses that external clients may be given.
match-destinations { address_match_list }; # the address(es) given to
external clients for their DNS service.
  ...
};
view "internal" {
   # there is no `match clients`. Any client not already match by the
"external" view potentially has access to this view, if they target the
correct service address(es).
  match-destinations { address_match_list }; # the address(es) given to
internal clients for their DNS service. Different from the one(s) given to
external clients.
  attach-cache "external"; # internal clients have access to records that
have already been cached due to queries made by external clients.
   ...
};

Greg

On Sat, 15 Oct 2022 at 18:52, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

> On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
> > If you are an ISP/registry/DNS provider, it makes sense to separate
> > authoritative zones for your clients' domains, for all those cases your
> > client move their domains somewhere else without notifying you (hell,
> > they do that too often), or to be able to prepare moving domains to your
> > servers.
>
> #truth
>
> > forward zones - named sends recursive query to the primary servers
> > stub zones- named fetches NS records from primary servers and
> > uses them for resolution
> > static-stub zones - named forwards iterative (non-recursive) requests to
> > primary servers
> >
> > clients accessing any of these zones must have recursion allowed and
> > recursion must be enabled in BIND.
>
> Please clarify where recursion needs to be allowed; the BIND server
> clients are talking to and / or the back end server that BIND is talking
> to on the client's behalf.
>
> I'm not completely clear and I think it's better to ask than to assume
> incorrectly.
>
> > On 10/15/22 10:03 AM, Bob McDonald wrote:
> >> If a non-secure client (read the next sentence...) accesses the same
> >> recursive server as a regular client, it will have access to the
> >> internal zones by default.. Therefore we need to have some sort of
> >> access controls in place.
> > and THIS is exactly the reason you SHOULD put your internal zones on
> > your internal server.
>
> Sorry if I'm being particularly dense this morning, but I'm not
> following ~> understanding Bob's and Matus's statements like I want to.
>
> How does hosting the zone on an internal server provide any additional
> security?  Or are you simply relying on other security mechanisms to
> prevent non-secure clients -- as Bob described them -- from accessing
> the server ~> zone?
>
> I feel like, by default -- as Bob described, any hosted zone is going to
> be accessible by any client that can query the server.
>
> With this in mind, I feel like the type of zone; primary / secondary /
> mirror / stub / static-stub / forward, makes little difference in and of
> itself.  Rather, it would be dependent on global and / or per-zone
> allow-* statements to protect the server / zone(s) at the BIND
> application level.
>
> Does that make sense?
>
> What am I missing / misunderstanding?
>
> > that's why we are here.
>
> :-)
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: caching does not seem to be working for internal view

[Greg Choules via bind-users]

Hi Robert.
May we see the file /etc/resolv.conf and your BIND configuration? It's
difficult to guess what might be going on with only a small snippet of
information.
If you "ping somewhere" (or "ssh a-server", or whatever) the OS will
consult resolv.conf to determine where to send DNS queries. If that's not
your local instance of BIND then you could be looking for trouble in the
wrong place.

If you *do* have an address of the local machine as the first 'nameserver'
entry in resolv.conf you will need to know what that query looks like to
determine how BIND is going to handle it.
You also need to know what BIND will try and do when it does receive
queries.

Packet captures are your friend here, using tcpdump (to disk, not to
screen). Gather evidence first, then make theories.

Cheers, Greg

On Wed, 3 Aug 2022 at 14:29, Robert Moskowitz  wrote:

> Part of my problem is that caching does not seem to be working in my
> internal view.
>
> Something is happening such that my internal systems AND the server
> itself cannot resolve names and looses it even 5 min later, indicating
> not caching.
>
> I read https://kb.isc.org/docs/aa-00851
>
> In my include for the internal view (named.internal) I have:
>
>  match-clients{ httnets; };
>  match-destinations{ httnets; };
>  allow-query{ httnets; };
>  allow-query-cache{ httnets; };
>  allow-recursion{ any; };
>  recursion yes;
>  empty-zones-enable yes;
>
> Yet I get on my DNS server:
>
> ping www.google.com
> ping: www.google.com: Name or service not known
>
> Then later it works.
>
> Then later it doesn't again.
>
> Sigh.  If at least caching was working for internal use, I would be able
> to work more smoothy?
>
>
>
>
> --
> 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: caching does not seem to be working for internal view

[Greg Choules via bind-users]

Hi Robert.
Turn on query logging by doing "rndc querylog". You should see a message
saying that has been done in "named.log", to where each query will now be
logged. If you have views, part of the query log will contain which view
was matched. So this will tell you two things:

   1. If the queries you are making are actually being handled by BIND at
   all.
   2. If they are, which view handled them.

Try that and see what you discover.

By the way, if you want to see a snapshot of the cache you will have to
dump it to disk using "rndc dumpdb -all", This will produce a file called
"named_dump.db" in the working directory. Commonly this will be the same
location as your zone files. It's a text file, so you can look through it
with cat/more/less etc.

Cheers, Greg

On Wed, 3 Aug 2022 at 21:23, Robert Moskowitz  wrote:

> This is boarderline not thinking on my part.
>
> OF COURSE those FQDNs resolve fast; they are in local ZOne files.  No
> lookup needed.
>
> Sheesh.
>
> "Slow down, you move to fast.  Got to make the Mornin' last!"  :)
>
> On 8/3/22 14:43, Robert Moskowitz wrote:
>
> Perhaps this is only caching the zones in the Internal View, not all
> public stuff looked up by internal clients?
>
> I say this because I get fast responses to internal servers, but slow if
> at all to external ones.
>
> Grasping here because my search foo is weak and I can't find where it is
> defined exactly what IS cached.
>
> On 8/3/22 10:52, Robert Moskowitz via bind-users wrote:
>
> thanks Greg.  Yes I need to figure out how to troubleshoot this.  But here
> is some stuff:
>
> # cat resolv.conf
> # Generated by NetworkManager
> search attlocal.net htt-consult.com
> nameserver 23.123.122.146
> nameserver 2600:1700:9120:4330::1
>
> My server is 23.123.122.146.  That IPv6 addr is my ATT router.
>
> # cat named.conf
> include "/etc/named/named.acl";
>
> options {
> listen-on port 53 { any; };
> listen-on-v6 port 53 { any; };
> use-v4-udp-ports { range 10240 65535; };
> use-v6-udp-ports { range 10240 65535; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { localhost; };
>
> dnssec-enable no;
> dnssec-validation no;
> bindkeys-file "/etc/named.iscdlv.key";
> managed-keys-directory "/var/named/dynamic";
> pid-file "/run/named/named.pid";
> session-keyfile "/run/named/session.key";
> };
>
> logging {channel default_debug {
> file "data/named.run";
> severity dynamic;};};
>
> view "internal"
> {include "/etc/named/named.internal";};
>
> view"external"
> {include "/etc/named/named.external";};
>
> include "/etc/named/rndc.key";
> include "/etc/named.root.key";
>
> # cat named.acl
> acl "httslaves"  {
> //address of NSs
> 208.83.69.35;// ns1.mudkips.net
> 208.83.66.130;// ns2.mudkips.net
> 63.68.132.50;// ns1.icsl.net
> 2607:f4b8:2600:1::1;// ns1.mudkips.net
> 2607:f4b8:2600:6::1;// ns2.mudkips.net
> };
>
> acl "httnets" {
> 127.0.0.1;
> 23.123.122.144/28;
> 192.168.32.0/24;
> 192.168.64.0/24;
> 192.168.96.0/24;
> 192.168.160.0/23;
> 192.168.128.0/23;
> 192.168.192.0/22;
> 192.168.224.0/24;
> ::1;
> 2600:1700:9120:4330::/64;
> };
>
>
> # cat named.internal
>
> match-clients{ httnets; };
> match-destinations{ httnets; };
> allow-query{ httnets; };
> allow-query-cache{ httnets; };
> allow-recursion{ any; };
> recursion yes;
> empty-zones-enable yes;
>
> zone "." IN {
> type hint;
> file "named.ca";};
>
> include "/etc/named.rfc1912.zones";
>
> zone "htt-consult.com" {
> type master;
> file "httin-consult.com.zone";};
>
> zone "labs.htt-consult.com" {
> type master;
> file "labs.htt-consult.com.hosts";};
> zone "intelcon.htt-consult.com" {
> type master;
> file "intelcon.htt-consult.com.hosts";};
> zone "mobile.htt-consult.com" {
> type master;
> f

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]

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: 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: 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: What is the meaning of an ecs log

[Greg Choules via bind-users]

Hi Mik.
The Client Subnet in DNS Queries  RFC
should explain all.
Essentially there are two masks in the ECS option - source prefix length
and scope prefix length.
ECS-enabled recursive servers (like Google or BIND -S edition) will set the
source prefix length to whatever has been configured; in this case /24. But
they MUST set the scope prefix length to zero because this field is
intended for use by an ECS enabled authoritative server to signal (in its
response) the prefix to which it applies.

I hope that helps.
Cheers, Greg

On Thu, 8 Dec 2022 at 07:04, Mik J via bind-users 
wrote:

> Thank you for your answer and pointing out this information.
>
> When I showed you this message
> client @0x53eda9122d0 172.16.11.2#48171 (example.org): query: example.org
> IN A -E(0)DC (1.2.3.4) [ECS 192.168.2.0/24/0
>
> This query was to my authoritative server which holds example.org
> The client IP is a Google DNS public IP (I had changed the IP to
> 172.16.11.2)
> And the 192.168.2.0/24 prefix is a prefix from a hosting company in
> Turkey (I had changed the IP)
>
> So I suppose that a machine hosted in that 192.168.2.0/24 subnet use
> google DNS as a resolver. And that resolver is quering my authoritative DNS.
>
> I had read the documentation and this /0 is noted as a scope
> "a statement which appears in a zone block has scope only for that zone"
> I understand this sentence but I don't understand this /0
>
> In my logs it's always a /0
> I'm wondering in which case it could be different that a /0
>
>
>
>
> Le jeudi 8 décembre 2022 à 02:36:40 UTC+1, Darren Ankney <
> darren.ank...@gmail.com> a écrit :
>
>
>
>
>
> Found the answer in the manual:
>
> "Finally, if any CLIENT-SUBNET option was present in the client query,
> it is included in square brackets in the format [ECS
> address/source/scope]."
>
> https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-category
>
> On Wed, Dec 7, 2022 at 8:25 PM Mik J via bind-users
>  wrote:
> >
> > Hello Daren,
> >
> > The entire message is
> > client @0x53eda9122d0 172.16.11.2#48171 (example.org): query:
> example.org IN A -E(0)DC (1.2.3.4) [ECS 192.168.2.0/24/0]
> >
> > The version is: 9.18.7
> > It's both autoritative and recursive
> >
> >
> >
> >
> > Le jeudi 8 décembre 2022 à 01:56:57 UTC+1, Darren Ankney <
> darren.ank...@gmail.com> a écrit :
> >
> >
> >
> >
> >
> > Is that the entire log message or just part of it?  Is this a
> > recursive or authoritative name server?  What version of bind?
> >
> > Logging is covered in the manual though I don't really see a
> > comprehensive explanation of message format (maybe it's there and I'm
> > just not seeing it).
> >
> https://bind9.readthedocs.io/en/v9_18_9/reference.html#logging-block-grammar
> >
> > On Wed, Dec 7, 2022 at 7:42 PM Mik J via bind-users
> >  wrote:
> > >
> > > Hello,
> > > I see logs like [ECS 192.168.2.0/24/0] but I don't understand what is
> the last /0 part.
> > > Where can I get an explanation ?
> > > Regards
> > --
> > 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
>
-- 
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 configure , dig command support +subnet

[Greg Choules via bind-users]

Hello.
What exact version of BIND are you running? "named -V" From dig it *looks*
like you are running 9.18.9.
ECS support only exists in the subscription editions of BIND (-S suffix)
and to get that you need to be an eligible ISC support customer.

Thanks, Greg

On Tue, 13 Dec 2022 at 10:48, 徐娅  wrote:

> 25-Nov-2022 23:30:32.924 running on Linux x86_64 3.10.0-1127.el7.x86_64 #1 
> SMP Tue Mar 31 23:36:51 UTC 202025-Nov-2022 23:30:32.924 built with  
> '--prefix=/usr/local/bind-9.18.9' '--enable-largefile' '--enable-epoll' 
> '--enable-full-report' '--disable-doh' '--enable-dnsrps-dl' 
> '--enable-dnsrps'25-Nov-2022 23:30:32.924 running as: named -c named.conf 
> -fg25-Nov-2022 23:30:32.924 compiled by GCC 4.8.5 20150623 (Red Hat 
> 4.8.5-39)25-Nov-2022 23:30:32.924 compiled with OpenSSL version: OpenSSL 
> 1.0.2k-fips  26 Jan 201725-Nov-2022 23:30:32.924 linked to OpenSSL version: 
> OpenSSL 1.0.2k-fips  26 Jan 201725-Nov-2022 23:30:32.924 compiled with zlib 
> version: 1.2.725-Nov-2022 23:30:32.924 linked to zlib version: 
> 1.2.725-Nov-2022 23:30:32.924 
> 25-Nov-2022 23:30:32.924 
> BIND 9 is maintained by Internet Systems Consortium,25-Nov-2022 23:30:32.924 
> Inc. (ISC), a non-profit 501(c)(3) public-benefit25-Nov-2022 23:30:32.924 
> corporation.  Support and training for BIND 9 are25-Nov-2022 23:30:32.924 
> available at https://www.isc.org/support
>
>
>
> # cat named.conf... .. ...options {listen-onport 353 { any; };
> listen-on-v6 port 353 { any; };directory   "/root/edns/named";
> allow-query { any;};allow-recursion { any;};
> empty-zones-enable no;pid-file "/root/edns/named/run/named.pid";};view 
> "aaa" {match-clients {10.105.0.0/16;   };zone "abc.com" {
> type master;file "aaa/abc.com";};};view "bbb" {match-clients 
> { 10.106.0.0/26;   };zone "abc.com" {type master;file 
> "bbb/abc.com";};};view "idc-default" {match-clients {  any;  };
> zone "abc.com" {type master;file "any/abc.com";};};# cat 
> named/aaa/abc.com... ...www 600 IN TXT aaa# cat named/bbb/abc.comwww 600 IN 
> TXT bbb# cat named/ccc/abc.comwww 600 IN TXT ccc
>
>
> # dig @127.0.0.1 -p 353 txt.abc.com txt +subnet=10.105.2.2; <<>> DiG 9.18.9 
> <<>> @127.0.0.1 -p 353 txt.abc.com txt +subnet=10.105.2.2; (1 server found);; 
> global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: 
> NOERROR, id: 7948;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, 
> ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 1232; 
> COOKIE: 075abe1b7a9c177a01006380ded9dc3ca0fc1bae43d4 (good); 
> CLIENT-SUBNET: 10.105.2.2/32/0;; QUESTION SECTION:;txt.abc.com.   
> IN  TXT;; ANSWER SECTION:txt.abc.com.   600 IN
>   TXT "any";; Query time: 1 msec;; SERVER: 127.0.0.1#353(127.0.0.1) 
> (UDP);; WHEN: Fri Nov 25 23:27:21 CST 2022;; MSG SIZE  rcvd: 99
>
> I expect +subnet=10.105.2.2, return *aaa*, but returned any
>
> # dig @127.0.0.1 -p 353 txt.abc.com txt +subnet=10.105.2.2any
>
> I expect +subnet=10.106.3.3, return *bbb*, but returned any
>
> # dig @127.0.0.1 -p 353 txt.abc.com txt +subnet=10.106.3.3any
>
>
> How do I change named.conf?
>
> --
> 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  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: 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: 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: 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: 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: 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: 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  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-clients { key "external.example.com"; !key "internal.example.com";
> any; };
>   zone "example.com" IN {
> # some other config, master zone
> allow-transfer { key "external.example.com"; };
> notify yes;
>   };
> };
>
> Note that I've included "internal-networks" in the internal view. This is
> simply to illustrate that you might also want the view to answer DNS
> requests from clients within your network.
>
> There is one further improvement on the above, which is what Mark referred
> to below, which is where each view can include the 

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.
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 (6) 12 98 08 07*
> *Email: j

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://yiximeta.com> De infor

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 onbedoeld
> ontvangen? Dan ve

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

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"; };
> allow-transfer { nameservers; };
> notify yes;
>   };
>   #trimmed spare zones
> };
>
> view "external" {
> match-clients { key external; any; };
> server 172.16.20.23 {
>   keys external;
>   provide-ixfr yes;
> };
> allow-transfer { nameservers; };
> allow-query { any; };
> allow-recursion { none; };
> recursion no;
> zone "." {
>   type hint;
>   file "/etc/named.ca";
> };
> zone "example.org" {
>   type master;
>   file "/master/example.org.external.hosts";
>   allow-transfer { nameservers; };
>   notify yes;
> };
>   #trimmed spare zones
> };
>
>
> ### trace:
>
> ; 

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-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.148
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.139
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.146
>
> ;; Query time: 202 msec
> ;; SERVER: 198.6.1.1#53(198.6.1.1) (UDP)
> ;; WHEN: Thu Feb 02 18:35:50 EST 2023
> ;; MSG SIZE  

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 progress: 0
> query logging is ON
> recursive clients: 138/9900/1
> tcp clients: 0/150
> TCP high-water: 1
> server is up and running
>
>
> -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 

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: 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: 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: 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=all_name%5B%5D=Extended%20DNS%20Errors_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: 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: 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.
>
>
> My question is, is there any way to "properly" return a hostname/IP based
> on what network the request is coming from?
>
> This seemed like it would work, and it kind of did, but even with a
> separate view of "any" for the hostnames of the production domain, this
> didn't quite work.
>
>
> I know this is a somewhat confusing set 

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

[Greg Choules via bind-users]

   file "/var/lib/bind/db.10.168.192.in-addr.arpa";
> update-policy {
>   grant ddns-key wildcard *.10.168.192.in-addr.arpa PTR;
> };
>   };
> };
>
> The contents of /var/lib/bind/db.system.lab.domain.com.192.168.10:
> $ORIGIN .
> $TTL 604800 ; 1 week
> system.lab.domain.com IN SOA ns1.domain.com. thatrat.gmail.com. (
> 2023062800 ; serial
> 604800 ; refresh (1 week)
> 86400  ; retry (1 day)
> 2419200; expire (4 weeks)
> 604800 ; minimum (1 week)
> )
> NS  ns1.domain.com.
> $ORIGIN system.lab.domain.com.
> A   192.168.10.170
>
> The other /var/lib/bind/db.system.lab.domain.com.10.32.X.X follow a
> similar format with the domain name pointing to a different IP address for
> each "version" of the domain matching a view for a different entry subnet.
>
> Again, the domain.com zone currently has an entry for
> system.lab.domain.com for 192.168.10.170 and the secondary lab.domain.com
> has an entry for system.lab.domain.com with 10.32.10.1.
>
> This was all working perfectly until I added the secondary domain to my
> config [essentially just the contents of the main view above] which it
> started only returning 10.32.10.1 for the system.lab.domain.com which
> again I think had some type of precedence on the "fuller" FQDN being
> served, and the system.lab from the domain.com zone taking lesser
> precedence.
>
> It also seems that the bind configuration file is read from top down in
> processing order?  I had the main view on top first, but then moved it
> below the other views, and then the 192.168.10-net view worked...but the
> main view did not work.
>
> I know this is an overly complicated setup and probably the simplest
> answer is just to remove the secondary zone from config so that there is
> only the one entry that resolves for the system.lab.domain.com, I just
> thought that there might be a away to have the hostname resolve differently
> based on what the requesting IP address was.
>
> I also have Dynamic DNS setup so that the ISC DHCP server will update
> domain.com with system hostname info which *might* complicate things.
>
>
> On Wed, Jun 28, 2023 at 9:33 PM Greg Choules <
> gregchoules+bindus...@googlemail.com> wrote:
>
>> 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 s

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 logs for what got transferred.
>>
>> I don't und

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 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
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.isc.org/pipermail/bind-users/attachments/20230616/42776b6c/attachment-0001.htm
> >
>
> --
>
> Message: 3
> Date: Fri, 16 Jun 2023 21:40:11 -0700 (PDT)
> From: Fred Morris 
> To: "bind-users@lists.isc.org" 
> Subject: Re: replace "SERVFAIL" to 

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 ?
> Kind regards
>
> -- 

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: 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?)
>
>
> --
>
> Message: 1
> Date: Fri, 16 

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: 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
>  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
>  
> 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: acl in also-nofify

[Greg Choules via bind-users]

Hi both.
You can't do it using ACLs. But you can do it using primaries. This is
hinted at in the section about the primaries statement, but not clearly
expanded on.
For example:

# define a primaries list called "also-notifed" (or anything you like).
Define as many lists as you need.
primaries also-notified {a.b.c.d; e.f.g.h;};
...
zone "example.com {
   type primary;
   file "db.example.com";
# apply the primaries list (or lists) to the also-notify statement.
   also-notify {also-notified;};
};

I hope that helps.
Cheers, Greg



On Thu, 8 Feb 2024 at 21:55, Elmar K. Bins  wrote:

> Randy,
>
> ra...@psg.com (Randy Bush) wrote:
>
> > can i use an acl{} or other macro in `also-notify`?  i have a bunch of
> > zones where i want the same `also-notify` list.
>
> Been running into the same issue and tried to find out. My master lists
> and acls
> are identical as yours seem to be. I've been told that internally they are
> very
> different and handled differently, so I had to duplicate my work (yes,
> they're
> copy+paste for me) :-(
>
> Best,
> Elmar.
>
>
> --
> 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: Re: zone not loaded in one of view

[Greg Choules via bind-users]

Hi.
The existence of a `.jnl` file for the zone means that, at some point in
the past anyway, you *did* allow dynamic updates to this zone and some
updates were made, which were stored in the journal file.

I would like to ask a couple of questions:
1) What is the timeline of your investigation? Map out file creation and
modification dates and times along with log messages and times you made
changes to see if you can build a picture of what actually happened when.
2) How many instances of 'named' are running on this server? I have seen in
the past people have two or more 'named' processes running that they were
not aware of, which *might* cause problems if they are trying to use the
same data files.

Cheers, Greg

On Tue, 19 Dec 2023 at 08:26,  wrote:

> I found there was a db.ynu.edu.cn.intranet.jnl beside db.ynu.edu.cn.intranet, 
> I tried to remove it, then restarted and checked the new cache_dump.db, no 
> `zone not loaded` anymore.
>
> For the original problem, because I modified serial of SOA and updated bind9 
> to the latest version, it could not reproduce. Maybe it's also the similar 
> issue, but in the older bind 9.11, no jnl file generated via named.
>
>
>
>
> 2023-12-17 15:47:43 "Mark Andrews"  写道：
>
> Read your logs and/or use named-checkzone and/or tell name-checkconf to
> load the zones.
>
> --
> Mark Andrews
>
> On 17 Dec 2023, at 15:22, liudong...@ynu.edu.cn wrote:
>
> Hi, I have a bind9 authoritative name server running, but I found a
> strange problem. One of zone in a specific view not loaded when I view the
> cache_dump.db after I execute `rndc dumpdb -all`.
>
>
> The zone data file is almost the same for difference views execpted some
> few domain resolution.
>
>
> [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.cernet
> $TTL 86400  ; 1 day
> @   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
> 2023121601;   serial number
> 10800   ;   Refresh interval, every 3 hours
> 3600;   Retry interval, every 30
> minutes
> 604800  ;   Expire after 1 week
> 86400 ) ;Minimum TTL of 1 day
>
>
> $INCLUDE /etc/named.data/db.ynu.edu.cn.common
>
>
>
>
> ; RR of type A
> ;
> vpn110800   IN  A   113.55.110.251
> ;
> lb-http-jz  IN  A   113.55.14.52
> ynucdn  600 IN  A   202.203.208.4
> ;
> vpn2IN  A   202.203.208.9
>
>
> [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.intranet
> $TTL 86400  ; 1 day
> @   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
> 2023121601;   serial number
> 10800   ;   Refresh interval, every 3 hours
> 3600;   Retry interval, every 30
> minutes
> 604800  ;   Expire after 1 week
> 86400 ) ;Minimum TTL of 1 day
>
>
> $INCLUDE /etc/named.data/db.ynu.edu.cn.common
>
>
>
>
> ; RR of type A
> ;
> lb-http-jz  IN  A   113.55.14.52
> ;
> vpn110800   IN  A   192.168.208.3
> ynucdn  600 IN  A   202.203.208.4
> ;
> vpn2IN  A   202.203.208.9
>
>
> [root@pridns data]#
> [root@pridns data]# named-checkconf /etc/named.conf
> [root@pridns data]# echo $?
> 0
> [root@pridns data]#
> [root@pridns data]# rndc zonestatus ynu.edu.cn in CERNET
> name: ynu.edu.cn
> type: primary
> files: db.ynu.edu.cn.cernet, /etc/named.data/db.ynu.edu.cn.common
> serial: 2023121601
> nodes: 576
> last loaded: Sat, 16 Dec 2023 08:00:49 GMT
> secure: no
> dynamic: no
> reconfigurable via modzone: no
> [root@pridns data]#
> [root@pridns data]# rndc zonestatus ynu.edu.cn in INTRANET
> rndc: 'zonestatus' failed: zone not loaded
> [root@pridns data]#
> [root@pridns data]# named-checkzone ynu.edu.cn
> /etc/named.data/db.ynu.edu.cn.intranet
> zone ynu.edu.cn/IN: loaded serial 2023121601
> OK
> [root@pridns data]#
> [root@pridns data]# ll /etc/named.data/db.ynu.edu.cn.cernet
> /etc/named.data/db.ynu.edu.cn.intranet
> -rw-r--r-- 1 root root 1.3K Dec 16 16:00
> /etc/named.data/db.ynu.edu.cn.cernet
> -rw-r--r-- 1 root root 1.3K Dec 16 16:00
> /etc/named.data/db.ynu.edu.cn.intranet
> [root@pridns data]#
>
>
> And here is parts of content in /var/named/data/cache_dump.db
>
>
> ; Zone dump of 'ynu.edu.cn/IN/INTRANET'
> ;
> ; zone not loaded
> ;
> ; Zone dump of 'rpz/IN/INTRANET'
>
>
>
>
> --
> 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
> 

Re: How do I debug if the queries are not getting resolved?

[Greg Choules via bind-users]

I really wouldn't recommend that.
If you have to, create exceptions for domains that won't validate correctly
by using the "validate-except {..." statement.
In parallel with that, encourage people with broken domains to fix them,
which makes life better for all of us.

Cheers, Greg

On Tue, 12 Dec 2023 at 17:42, Blason R  wrote:

> Thanks folks
>
> I just disabled DNSSEC validation from bind config file (globally) and
> those domains started resolving fine.
>
>
> On Tue, Dec 12, 2023, 13:25 Greg Choules <
> gregchoules+bindus...@googlemail.com> wrote:
>
>> Hello.
>> There are well known and documented issues with the zone "gov.in" and
>> there were some recent problems with "gov" as well.
>> Please search this mailing list archive for those domains and you may
>> find some useful hints, tips and information that explain and help you with
>> your own problem.
>>
>> Cheers, Greg
>>
>> On Tue, 12 Dec 2023 at 00:48, Blason R  wrote:
>>
>>> Oh I forgot to tell you that. This is BIND RPZ and all the queries are
>>> recursive.
>>>
>>> Dig output just dies out and does not spit anything.
>>>
>>> And this specifically i noticed with .gov and .gov.in domain. This is
>>> the reason I thing it might be related with DNSSEC.
>>>
>>> Also wanted to understand overall how do I debug any queries.
>>>
>>> On Tue, Dec 12, 2023, 00:28 Marco Moock  wrote:
>>>
>>>> Am 11.12.2023 um 23:37:36 Uhr schrieb Blason R:
>>>>
>>>> > I require assistance in troubleshooting the resolution issue for
>>>> > specific domains that are not being resolved properly. The version of
>>>> > BIND I am currently using is BIND 9.18.20-1.
>>>>
>>>> First, tell us if those queries are authoritative on that server or not.
>>>>
>>>> Try using dig and post the output here.
>>>> --
>>>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>>>> from this list
>>>>
>>>> ISC funds the development of this software with paid support
>>>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>>>> information.
>>>>
>>>>
>>>> bind-users mailing list
>>>> bind-users@lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>>
>>> --
>>> 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 do I debug if the queries are not getting resolved?

[Greg Choules via bind-users]

Hello.
There are well known and documented issues with the zone "gov.in" and there
were some recent problems with "gov" as well.
Please search this mailing list archive for those domains and you may find
some useful hints, tips and information that explain and help you with your
own problem.

Cheers, Greg

On Tue, 12 Dec 2023 at 00:48, Blason R  wrote:

> Oh I forgot to tell you that. This is BIND RPZ and all the queries are
> recursive.
>
> Dig output just dies out and does not spit anything.
>
> And this specifically i noticed with .gov and .gov.in domain. This is the
> reason I thing it might be related with DNSSEC.
>
> Also wanted to understand overall how do I debug any queries.
>
> On Tue, Dec 12, 2023, 00:28 Marco Moock  wrote:
>
>> Am 11.12.2023 um 23:37:36 Uhr schrieb Blason R:
>>
>> > I require assistance in troubleshooting the resolution issue for
>> > specific domains that are not being resolved properly. The version of
>> > BIND I am currently using is BIND 9.18.20-1.
>>
>> First, tell us if those queries are authoritative on that server or not.
>>
>> Try using dig and post the output here.
>> --
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>> from this list
>>
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
> --
> 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: Question about DNS / bind9 / authoritative and NXDOMAIN vs NOERROR (NODATA)

[Greg Choules via bind-users]

Hi Michel.
You will get an authoritative answer (AA bit = 1) if the server is either
primary (master) or secondary (slave) for the QNAME (query name); in this
case "reseau1.lan". From the config snip you provided this is because you
have the config:

zone "reseau1.lan" {
   type master;
...
};

If you make a query for "xxx.reseau1.lan" to this server, the response you
get back will depend on whether you have anything in the zone file
("db.reseau1.lan")
that would match that QNAME. If you do not have "xxx" or "*" (wildcard)
then there will be no match and the response will be (authoritative)
NXDOMAIN - this name does not exist at all.
Personally I would not use a wildcard because it gives the impression that
any name exists when really it doesn't.

NOTE that the existence of "reseau1.lan" means that ALL names beneath this
point will be swallowed by the server, e.g. "a.b.c.d.e.f.reseau1.lan" will
all return NXDOMAIN +AA=1

What behaviour do you think you would like to see?

Looking at another part of your config, you should not need this at all:

options {
   forwarders {8.8.8.8;};
...
};

If your server can reach the Internet it can recurse all on its own.

I hope that helps.
Greg

On Wed, 13 Dec 2023 at 16:29, Michel Diemer via bind-users <
bind-users@lists.isc.org> wrote:

>
> ‌
> Dear Bind user,
>
> I am a teacher and trying to understand how dns works. I am spending hours
> reading various sources without finding satisfying information. For
> teaching purposes I have created a virtual machine with isc dhcp server and
> bind9 and another virtual machine that uses the first one as ics dhcp and
> dns server.
>
> I have disabled IPv6 by setting link-local: [] in netplan's setting.
>
> The name of the network (dns zone) is "reseau1.lan". When I "dig -4
> reseau1.lan" the AUTHORITY bit is set to 1.
>
> Why or when should the AUTHORITY bit set to 1 ? What does it take for
> nslookup to give me an authoritative answer ?
>
> If I "ping xxx.reseau1.lan" I get an NXDOMAIN answer. Why NXDOMAIN and not
> NOERROR (NODATA) ? The domain "reseau1.lan" exists and my dns server is
> authoritative for this zone (SOA record) but the computer "xxx" on this
> domain does not. Should I use a wildcard dns record ?
>
> I have tryed to empty the list of forwarders and disable the dns cache ...
> should I configure a dns-resolver only for the domain reseau1.lan and then
> a dns forwared for external dns queries ? Or maybe configure the resolver
> for the lan network interface and the forwarder on the internet network
> interface on the dns server ?
>
> I managed to get "AUTHORITY: 1" when typing "dig -4 soa reseau1.lan" by
> disabling the forwarders and the cache so I guess I should configure bind
> per network interface. But when typing "dig -4 pc1.reseau1.lan" the
> AUTHORITY bit is always set to 0.
>
>
> ͏‌
>
>
>
> ͏‌
>
>
> Kind Regards,
>
> Michel Diemer
> --
> 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: Question about authoritative server and AA Authoritative Answer

[Greg Choules via bind-users]

Hi Michel.
Please can you send the following information:
- name and IP address of the authoritative server
- the full contents of the zone file for "reseau1.lan"
- name and IP address of the other server - what does this server do?
- What is the machine "pc1", on which you are running the digs?
- the file "/etc/resolv.conf" on "pc1"

Please also re-send the digs with full output.
When you send information, please send it as text, not screenshots.

Thanks, Greg

On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users <
bind-users@lists.isc.org> wrote:

> ‌Ders bind users,
>
> I have already asked a similar question which was more about DNS in
> general , this one is very specific about the AA bit.
>
> Today's question is : *« "dig pc1.reseau1.lan ns"** show AUTHORITY: 1 and
> "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I
> missing ? If possible, how to get AA answers for QNAME queries ? »*
>
> I have set up two virtual machines on a virtual local network using Oracle
> VirtualBox. One machine is a DNS authoritative-only server. The zone is
> named "reseau1.lan" and defined only in bind9 zone files. If I really have
> to, I will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan
> inspired by RFC 6762 appendix G). The IP address of the DNS server is
> 172.16.0.254 and the IP address of pc1 is 172.16.0.21.
>
>
> *dig soa reseau1.lan* : the AA bit is set, which is what I am looking for
>
> ͏‌ ͏‌ ͏‌
>
> * dig pc1.reseau1.lan ns* :  the AA bit is set
>
> ͏‌ ͏‌ ͏‌ ͏‌
>
> *dig pc1.reseau1.lan* : *the AA bit is not set. Why ? Which setting or
> knowledge am I missing ?*
>
>
>
> Below my "named.conf.options" file
>
> ͏‌
>
>
> ͏‌ ͏‌ ͏‌ ͏‌
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Question about authoritative server and AA Authoritative Answer

[Greg Choules via bind-users]

Hi again.
Please start a packet capture on the auth server. This should do it:
   sudo tcpdump -nvi any -c 1 -w mydns.pcap port 53
Then from pc1, please do these and copy/paste text output, not screenshots:

dig @172.16.0.254 pc1.reseau1.lan NS +norecurse
dig @172.16.0.254 pc1.reseau1.lan SOA +norecurse
dig @172.16.0.254 pc1.reseau1.lan A +norecurse
dig @172.16.0.254 pc1.reseau1.lan  +norecurse

Now stop the packet capture on the auth server and send all the information.

The reason for using @ with dig is to eliminate the stub
resolver on pc1 itself.

Thanks, Greg




On Wed, 17 Jan 2024 at 12:59,  wrote:

> ‌
> ‌
> Dear Greg,
> Dear Mark,
>
> Once more thank you for your replies. Please see highlighted words below.
>
> I confirm that 172.16.0.254 is the dns authoritative server.
>
>  'pc1' means 'a generic computer on a local area network'. It could be a
> web server, a file server, a mail server. For a small structure with fixed
> ip addresses only, it could be a user's pc. On pc1 there is a fresh install
> of ubuntu 22.04 with only a few network settings (dhcp, dns, gateway). I
> created it only to test various network settings (dynamic dns, fixed ip
> address, dhcp provided ip address, ...).
>
> For this specific question about authoritative server, pc1 has a fixed ip
> address. Ubuntu's networkd-resolved local dns caching and stub is disabled,
> (Cache=no, DNSStubListener=no). For this specific question, I have only
> two computers, one authoritative non-recursive dns server and a generic
> computer named pc1.
>
>
> Please have a look at the highlighted text below to understand my question
> :
>
> Command dig pc1.reseau1.lan *ns*
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> *AUTHORITY: 1 : this is ok.*
>
>
> Command dig pc1.reseau1.lan
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> *Why AUTHORITY: 0 and not AUTHORITY: 1 ???*
>
> De : "Greg Choules" 
> A : pub.dieme...@laposte.net,bind-users@lists.isc.org
> Envoyé: lundi 15 Janvier 2024 18:27
> Objet : Re: Question about authoritative server and AA Authoritative Answer
>
> Hi again and thanks for that.
> I'm still not exactly clear on the setup. I think the auth server is
> 172.16.0.254 (I don't know what pc1 is).
> But anyway, looking at your results I see the AA bit for everything. It
> appears that these queries both went directly to the auth server because
> recursion is disabled and it told you so.
>
> ==
>
> # pc1@pc1:~
> dig pc1.reseau1.lan
> ```
>
> ```txt
> ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> # ns1@ns1:~
> dig pc1.reseau1.lan
> ```
>
> ```txt
> ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ==
>
> So unless I'm missing something I don't see your problem.
> Cheers, Greg
>
> On Mon, 15 Jan 2024 at 15:24,  wrote:
>
>> D‌ear Greg,
>>
>> Thank you for your reply.
>>
>>
>> Please find attached the markdown file  with all the commands and text
>> from the terminal.
>>
>> In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener
>> from systemd-resolved. I have netplan and networkd.
>>
>>
>> Kind Regards,
>>
>> Michel Diemer.
>>
>>
>>
>> De : "Greg Choules"
>> A : pub.dieme...@laposte.net,bind-users@lists.isc.org
>> Envoyé: dimanche 14 Janvier 2024 23:28
>> Objet : Re: Question about authoritative server and AA Authoritative
>> Answer
>>
>> Hi Michel.
>> Please can you send the following information:
>> - name and IP address of the authoritative server
>> - the full contents of the zone file for "reseau1.lan"
>> - name and IP address of the other server - what does this server do?
>> - What is the machine "pc1", on which you are running the digs?
>> - the file "/etc/resolv.conf" on "pc1"
>>
>> Please also re-send the digs with

Re: Problem with recursion for windows bind for Teamviewer

[Greg Choules via bind-users]

Hi there.
Can you send some information, for those unfamiliar with what you're trying
to do?
- Full BIND config
- IP addresses of relevant things, like interfaces of the servers on which
you are running BIND and of Teamviewer.
- What does Teamviewer need from DNS? What kinds of queries is it making
and to where? A binary pcap would be very useful.
- Is this an AD environment? i.e. do you have Domain Controllers and other
such AD components?
- How are your Windows boxes configured to use DNS? What IP address(es) do
they get given and what are those addresses?

Diagnosing a problem is difficult if you only have snippets of information
to work from.

Cheers, Greg

On Mon, 20 Nov 2023 at 13:48, legacyone via bind-users <
bind-users@lists.isc.org> wrote:

> Now its not working fast again! I don't know now must be Teamviewer DNS
> delaying replies causing windows bind to fail in some way.
> --
> 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: Problem with recursion for windows bind for Teamviewer

[Greg Choules via bind-users]

Have you checked the routeing table on this server?
Without any other evidence, this looks to me like packets are going places
you aren't expecting.

In the first screenshot the query goes to 213.227.191.1 and apparently a
response doesn't come back until 4s later. When I try it using dig I get an
immediate response:

; <<>> DiG 9.18.17 <<>> @213.227.191.1 router14.teamviewer.com +norecurs
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32608
;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;router14.teamviewer.com. IN A

;; ANSWER SECTION:
router14.teamviewer.com. 3600 IN CNAME routerpool14.rlb.teamviewer.com.
routerpool14.rlb.teamviewer.com. 120 IN A 188.172.219.139
routerpool14.rlb.teamviewer.com. 120 IN A 188.172.198.141
routerpool14.rlb.teamviewer.com. 120 IN A 37.252.232.103
routerpool14.rlb.teamviewer.com. 120 IN A 37.252.246.104
routerpool14.rlb.teamviewer.com. 120 IN A 217.146.4.136

;; Query time: 11 msec
;; SERVER: 213.227.191.1#53(213.227.191.1) (UDP)
;; WHEN: Mon Nov 20 17:40:22 GMT 2023
;; MSG SIZE  rcvd: 177

In the second screenshot you see no response to #60. My suspicion again is
that it went somewhere you weren't monitoring, or just wasn't routed at all.

I would capture ALL packets, not just DNS, on ALL interfaces. See if you
can see where key packets are going, whether you receive ICMP unreachables
or retries etc.
Also do some tests. If you have BIND you should also have dig. If you don't
have dig, use Windows nslookup in interactive mode and send queries to the
teamviewer NSs.

Right now I would prove that the network is clean first. I see no reason to
suspect BIND at the moment.

Cheers, Greg

On Mon, 20 Nov 2023 at 17:40, legacyone via bind-users <
bind-users@lists.isc.org> wrote:

> This might show the problem even more on two interfaces WAN side and LAN
> you can see 192.168.53.19 ask for routerpool8 #60 then bind goes out #62
> gets a answer # 75 and no reply back to 192.168.53.19
>
> https://ufile.io/v8oob3jg
> --
> 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