Re: CDNSKEY / CDS for key is now published - but why?

[Greg Choules via bind-users]

Hi Danilo.
The CDS and CDNSKEY are published in your own zone, not anywhere else. You
can confirm this by doing a dig for them directly, or AXFR if you permit
transfers on your server.

They are intended for use with registrars that *do* support automatic DS
creation using one of them. If yours doesn't and you already published your
DS in the parent, then no big deal. The CDS and CDNSKEY will just sit in
your zone and you don't have to do anything with them.

Does that help?
Cheers, Greg

On Wed, 2 Oct 2024 at 10:58, Danilo Godec via bind-users <
bind-users@lists.isc.org> wrote:

> Hi all,
>
> yesterday I filled my day fiddling with DNSSEC for a couple of my test
> domains - both have been signed 'manually' before, but I haven't published
> the DS record.
>
>
> So yesterday I setup both for dnssec-policy, while also changing the
> signing algorithm and keys (basically started from scratch):
>
> dnssec-policy "nsec3_no_rotate" {
> keys {
> ksk key-directory lifetime unlimited algorithm 13;
> zsk key-directory lifetime unlimited algorithm 13;
> };
> nsec3param iterations 0 optout false;
> };
>
> ...
>
> zone "sociopat.si" {
> type master;
> file "master/Danci/sociopat.si.hosts";
> key-directory "master/Danci/keys";
> dnssec-policy "nsec3_no_rotate";
> inline-signing yes;
> };
>
> zone "psihopat.si" {
> type master;
> file "master/Danci/psihopat.si.hosts";
> key-directory "master/Danci/keys";
> dnssec-policy "nsec3_no_rotate";
> inline-signing yes;
> };
> ...
>
>
> I published DS records through my registrar and after a couple of hours
> all seemed fine - both Verisign dnssec-analyzer and DNSViz show no errors
> or warnings for them.
>
>
> However, today bind logged this:
>
> named[17379]: general: info: CDNSKEY for key 
> sociopat.si/ECDSAP256SHA256/61220 is now published
> named[17379]: general: info: CDS for key sociopat.si/ECDSAP256SHA256/61220 is 
> now published
>
>
> I'm pretty sure this is not bad or wrong, but I would like to sort-of
> understand, why Bind decided it needs to publish CDS / CDNSKEY for this one
> and not the other one, given that DS records are published in ccTLDs:
>
> # dig ds sociopat.si
> ;; QUESTION SECTION:
> ;sociopat.si.   IN  DS
>
> ;; ANSWER SECTION:sociopat.si.5826IN  DS  61220 13 2 
> D8C1553B3D6BCF7A704A3D821069F57B6946DCA1D198D303E3B4C730 616F92AD
>
>
> # dig ds psihopat.si
>
> ;; QUESTION SECTION:
> ;psihopat.si.   IN  DS
>
> ;; ANSWER SECTION:psihopat.si.7200IN  DS  7162 13 2 
> 3C5A5625F848DBCF99A0B85017AFE04FD1F681037B61BE970D57AE9F 90F21CD8
>
>
>
> Also, as far as I know, .si DNS servers don't support CDS / CDNSKEY, so
> publishing them might be futile.
>
>
>   Regards,
>
>Danilo
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: Lookup failures

[Greg Choules via bind-users]

Hi Steven.
As you said, `listen-on {...;};` tells BIND which addresses to register for
incoming traffic. This can be a list, not just one address. Any query
received on (say) 10.0.0.1 will be responded to from the same address.

It is possible to choose which address to use for outgoing queries/fetches
as well, using `query-source address ...;`, which in the past I have used
and made different from the listen-on address(es) so that I can tell in
packet captures what is what. Also it's handy for firewall rules, keeping
client<>resolver traffic on different addresses from resolver<>world
traffic.

Is that what you wanted to know?
Cheers, Greg

On Fri, 13 Sept 2024 at 15:14, Steven Shockley 
wrote:

> On 9/12/2024 9:20 PM, Steven Shockley wrote:
> > I'll try to run some tcpdumps inbound and outbound tomorrow, traffic
> > should be pretty light.
>
> I did find something interesting that may or may not be related.
>
> The machine is also the Internet gateway.  One NIC has a vlan interface
> for each network; there's also a Cisco switch that routes between
> subnets.  The client-to-bind traffic routes via the Cisco switch, but
> BIND sends the response via the direct vlan interface.
>
> Bad ASCII art:
>
> Query:
> client --> (vlan102) --> switch --> (vlan101) --> DNS
>
> Response:
> DNS --> (vlan102) --> client
>
> Is there a way to tell BIND to listen (and respond) on a specific
> interface?  I already have listen-on { 10.0.0.1; }; (vlan101 IP) in the
> config with nothing else listening.
>
> I guess there's nothing technically wrong with this, but it does make it
> harder to troubleshoot.
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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 statistics

[Greg Choules via bind-users]

Latest Chrome/Safari/Firefox on MacOS as well and it looks good for me. I
haven't needed to clear cookies or browsing data or anything, it just
worked.

My 9.20.0 is running locally on the Mac, installed via homebrew. Maybe try
that and see what you get?
Perhaps it's something to do with the environment in which you have BIND
installed, or the particular build parameters.

Cheers, Greg

On Mon, 26 Aug 2024 at 07:49, Havard Eidnes  wrote:

> >> Hi Håvard.
> >> Have you tried a different browser?
> >
> > Not yet.  Will do tomorrow.
>
> Latest Chrome on MacOS: just the same; it displays the raw XML
> which isn't exactly user-friendly.
>
> 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

Re: BIND statistics

[Greg Choules via bind-users]

Hi Håvard.
Have you tried a different browser? Having said that, I just started 9.20.0
with this config:

statistics-channels { inet 127.0.1.0 port 8080 ; };

Then pointed three different browsers at that address/port and it looks
fine to me in all of them.
Browers tried were Chrome, Safari and Firefox.

I can't reproduce your issue, sorry.
Cheers, Greg

On Sun, 25 Aug 2024 at 21:06, Havard Eidnes via bind-users <
bind-users@lists.isc.org> wrote:

> Hi,
>
> I'm mostly running BIND 9.18.x, and have configured statistics
> publishing via
>
> statistics-channels {
> inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
> inet "actual-address" port 8053 allow { prefix1/24; prefix2/24; };
> };
>
> I've started testing 9.20.x.
>
> I see BIND 9.20.x stats publishing is ... different.
>
> If I use firefox and visit http://actual-address:8053/ with BIND
> 9.18.x, I get a reasonably rendered HTML display which is easy to
> view.
>
> Not so for BIND 9.20.x; I get an XML document which firefox (in
> this particular case version 120.0) informs me at the top
>
>This XML file does not appear to have any style information
>associated with it. The document tree is shown below.
>
> and the document starts with
>
> 
> 
> 
> 
> 
> 
> 
> 
> https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"/</a>>
> <script type="text/javascript">
> $(function($) { var wid=0; $('table.zones').each(function(i) { if(
> $(this).width() > wid ) wid = $(this).width(); return true; });
> $('table.zones').css('min-width', wid );
> $("h2+table,h3+table,h4+table,h2+div,h3+div,h2+script,h3+script").prev().append('
> <a class="tabletoggle" href="#" style="font-size:small">Show/Hide</a>
> '); $(".tabletoggle").click(function(){ var n =
> $(this).closest("h2,h3,h4").next(); if (n.is("script")) { n = n.next(); }
> if (n.is("div")) { n.toggleClass("hidden"); n = n.next(); } if (n.is("table"))
> { n.toggleClass("hidden"); } return false; }); });
> 
>
> and is quite different from what BIND 9.18.x presents:
>
> 
> 
>  version="3.13">2024-08-16T09:03:10.730Z
>
> etc. etc.
>
> The question is: am I alone in experiencing this?
>
> It also looks like I'll have to find out why collecting BIND
> stats via collectd (5.12.0) no longer works after upgrading to
> 9.20.x.
>
> 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: views-based RPZ

[Greg Choules via bind-users]

Hi Grant.
That doesn't work for zones that then get used in a `response-policy`
block. In this case you *must* define a zone §each time; so one (or up to
64) per view/instance of `response-policy`. Test it on your laptop/in a VM.
What this does mean is that (if you are using views) you *could* have a
different set of RPZ rules (different zone/zone contents) per view, perhaps
because certain domains are fine for one set of clients but not fine for
others.

@Carlos to respond to your mail from yesterday:
The 64 zone limit applies to the `response-policy` block (see above).
Here's the reference for that:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-response-policy
Since there can be only one `r-p` globally (if you don't have user-defined
views) or per view (if you do) it kinda amounts to the same thing, but I
just wanted to clarify.

Regarding view selection, I don't know exactly how the code works or how
efficient it is. But certainly I have seen some configs with a lot of views
and they seem to function OK.
What sort of QPS are each of your servers handling?

Cheers, Greg

On Sun, 25 Aug 2024 at 05:27, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

> On 8/24/24 07:37, Carlos Horowicz via bind-users wrote:
> > 2. if RPZ records are held in memory, why would an RPZ zone need to be
> > stored n times if there are n orthogonal views ? That is, why the more
> > views the more memory needed. Maybe you meant the qpcache, to store
> > different answers, though I don't understand how that works.
>
> I believe that some newer versions of BIND can share zone information
> across multiple views.  Check out the "in-view" statement that goes in a
> zone {...} clause.
>
> Link - Chapter 7 BIND zone clause
>   - https://www.zytrax.com/books/dns/ch7/zone.html#in-view
>
>
>
> --
> Grant. . . .
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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-based RPZ

[Greg Choules via bind-users]

Hi Carlos.
If you have enough RAM it should be possible to create multiple views, each
with a zone (primary or secondary, up to you) that contains the RPZ data
for that view and a response-policy that uses that zone.

The limit on number of zones is per response-policy block. But if you're
using separate blocks inside each view, each r-p block referring to only
one zone, then that limit is not relevant.

Bear in mind that views are processed top down, so if you have a lot of
them it can take a (relatively) long time to match clients to the ones at
the bottom. Also, by default, each view has its own cache, hence the need
for a lot of RAM.

I would try it out on a lab server first.

Hope that helps.
Cheers, Greg

On Fri, 23 Aug 2024 at 20:43, Carlos Horowicz via bind-users <
bind-users@lists.isc.org> wrote:

> Hello List,
>
> an ISP has brought a case where several customers do not agree with our
> web interface portal that lets select different RPZ zones to be activated
> for a set of resolvers that are common to all customers. They even belong
> to different countries where some domains are banned.
>
> Given the case that I start treating provisioned CIDRs from customers as a
> base for views, does bind9.18.* support a huge number of views with
> different rpz zones activated per view ?
>
> I recall having read in the documentation about a limitation of 64 rpz
> zones in total, is this a number that can be configured, or even be set to
> "unlimited"  ?
>
> Thanks in advance
>
> Carlos Horowicz
> Planisys
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: Behavior of 'forward only' zone

[Greg Choules via bind-users]

Hi John.
The reason is step 4c here:
https://datatracker.ietf.org/doc/html/rfc1034#section-5.3.3

The A record in the response is for a name that BIND wasn't asked for
(otherwise why a CNAME at all?), so in the interests of not just believing
random answers that might potentially poison the cache, BIND needs to check
for itself, even if the resulting fetch is sent to the same forwarder.

Your resolver somehow needs to be able to get an answer to the target of
the CNAME. Not knowing your setup I can't say *how* it could do this. But
possibly by forwarding that name, or a (grand)parent of that domain to
another resolver that can get the answer for it?

Hope that helps.
Cheers, Greg

On Tue, 20 Aug 2024 at 21:28, John Thurston 
wrote:

> We are asked to forward queries for foo.example.com to a set of private
> resolvers. So we have something like this in our .conf
>
> zone "foo.example.com" {type forward; forward only;
> forwarders { 10.1.2.3; 10.1.4.5; };
> };
>
> And when queried for an A-record for bar.foo.example.com (and the
> A-record exists), the query is forwarded, the answer is received, cached,
> and returned to the customer.
>
> But in the case where bar.foo.example.com is an alias to a record in some
> other domain (e.g. foo.baz.local), the behavior is different.
>
> With a packet capture, I can see the query being forwarded to one of the
> targets (with the 'recursion desired' bit set). I can see the reply coming
> back with the 'recursion available' bit set, and the answer containing the
> CNAME, and the ultimate A-record. The distant server has performed the
> requested recursion.
>
> My recursive server does not, however, return the final A-record to the
> customer. It attempts to resolve the intermediate CNAME, and (since the
> CNAME is to another private domain of which I have no knowledge) it fails.
> An NXDOMAIN is returned to the customer.
>
> I understood the 'type forward' to be a 'hand off'. My server would set
> the rd-bit, forward the query on, and accept (and return) whatever answer
> was received. If I'm correctly interpreting what I see, my server will
> accept whatever answer is received but only for exactly the zone named in
> zone-statement. When the answer contains an alias to some other domain, my
> server hands that name back into its own recursing process.
>
> Is there some way to configure BIND so it will simply pass back to the
> customer whatever answer is received from the distant resolver?
>
>
> --
> --
> 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: I want to know why I suddenly can't resolve names.

[Greg Choules via bind-users]

Hi.
Please, please, please upgrade your OS and BIND.

CentOS 6 went EoS 3 years ago, from what I can tell.
BIND 9.8 is 12 years old and there have been far too many changes and
security fixes in that time to list in a mail. If you want to see for
yourself, explore https://downloads.isc.org/isc/bind9/

When you are on current code, see if you need to ask the question again. I
think you won't.

Cheers, Greg

On Mon, 19 Aug 2024 at 09:45, 秋林峻祐  wrote:

>
> ***
> このメールの添付ファイルはSPC Mailエスティーにアップロードされました。
> 該当ファイルは以下のダウンロードページから取得してください。
> ダウンロードするためのパスワード情報は、別メールで通知されます。
>
> The attach file to this email has been uploaded to SPC Mail Estee for mail 
> safety purpose.
> Please obtain the corresponding files from download URL listed below.
>
> Password information for files download will be notified by separate email 
> shortly.
>
>
> https://cs8et.spcmail.jp/ETRTransfer_mail/DownloadStart?qprsuet=8b3ufcSGGLwYYqbyrKOo&p=20240819174505JgQXA5kVE9Z0g6KDUFWQYq4PtftX5nJfkWW5e5Vy7v6LcyF87dDLQ5bm1eiqKswE&pageId=download
>
> ※上記のURLは、このメールを受信された方の専用URLとなるため、
> 本メールの返信時や転送時は該当URLは削除してください。
> ※The download URL is solely dedicated to the person who receive this email,
>
> please delete the URL at the time of replying and/or forwarding to other 
> email address.
>
> ***
>
>>
>> Thanks for your reply.
>> Sorry, I was fundamentally mistaken, the “dnssec-lookaside” item was not
>> in the configuration file.
>> I am attaching the named.conf for your reference.
>>
>> I checked the contents of “/etc/named.iscdlv.key” and found the following
>> statement
>> -
>> # “dnssec-lookaside auto;”.  Without these options being set,.
>> # the keys in this file are ignored.
>> -
>> Since there is no “dnssec-lookaside” entry, I assume that the dlv key is
>> not used, so why did I get the error log for the dlv key expire this time?
>> I thought the solution was to delete “dnssec-lookaside”, but it was not
>> there originally.
>> I would like to know how to deal with it.
>>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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.16.27 - Cache Prefetch

[Greg Choules via bind-users]

Hi Gabe.
Prefetch still exists; reference here:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-prefetch

Hope that helps.
Greg

On Tue, 23 Jul 2024 at 17:36, Gabe Loyer  wrote:

> In searching for documentation I can only find something for prefetch in
> 9.10, which apparently caused some issues. Is there any new alternative in
> later versions?
>
> Thanks,
> Gabe
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: netstat showing multiple lines for each listening socket

[Greg Choules]

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

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

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

I hope that helps.
Greg


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

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

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


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

Re: zone_journal_compact: could not get zone size: not found

[Greg Choules via bind-users]

Hi Kees.
A few questions:
- What version of BIND are you running?
- How large (number of RRs) are your zones?
- What is the peak rate of dynamic updates?
- Do you have "max-journal-size" configured to anything?
- Are you perhaps getting short on disc storage in the place where BIND
keeps its files?
- How much RAM does the server have and how much of that is BIND using?

I would recommend reading the ARM section on the journal. The log message
itself comes from "zone.c"

Cheers, Greg

On Mon, 8 Jul 2024 at 12:18, Kees Bakker via bind-users <
bind-users@lists.isc.org> wrote:

> Hi,
>
> At the moment I have three FreeIPA systems (replicas), recently
> installed with CentOS 9-Stream.
> All three of these show this message at irregular intervals.
>
> Jul 03 07:50:44 iparep5.example.com named[541]: zone example.com/IN:
> zone_journal_compact: could not get zone size: not found
> Jul 03 07:50:51 iparep5.example.com named[541]: zone
> 16.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 07:51:03 iparep5.example.com named[541]: zone
> 17.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 07:51:34 iparep5.example.com named[541]: zone
> 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 07:52:12 iparep5.example.com named[541]: zone
> 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:03:51 iparep5.example.com named[541]: zone example.com/IN:
> zone_journal_compact: could not get zone size: not found
> Jul 03 08:04:52 iparep5.example.com named[541]: zone
> 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:06:30 iparep5.example.com named[541]: zone
> 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:18:42 iparep5.example.com named[541]: zone example.com/IN:
> zone_journal_compact: could not get zone size: not found
> Jul 03 08:20:19 iparep5.example.com named[541]: zone
> 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:26:23 iparep5.example.com named[541]: zone
> 30.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
> Jul 03 08:34:12 iparep5.example.com named[541]: zone example.com/IN:
> zone_journal_compact: could not get zone size: not found
> Jul 03 08:34:50 iparep5.example.com named[541]: zone
> 29.16.172.in-addr.arpa/IN: zone_journal_compact: could not get zone
> size: not found
>
> I have been running FreeIPA (including the bind nameserver) for several
> years now and I have never seen this message before.
> I still have one FreeIPA system running CentOS 8-Stream.
>
> Does anyone have a clue what it can be? Or how to find out? There are
> close to zero hits when I searched for this on the internet.
> How to debug this? (How to debug this in a production environment, ha ha)
> --
> Kees
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: forward option in dns server

[Greg Sloop]

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

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

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

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

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

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



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

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

Re: rolling my own hints file

[Greg Choules via bind-users]

Hi Brian.
You need the NS record(s) in hints because this is what a resolver wants
first; the name(s) of the NS for a given zone.
Regarding "@" or ".", they amount to the same thing in my example, though
perhaps I was being a bit lazy and minimal.

@ represents the name of the zone (or the most recent $ORIGIN declaration),
so in this case "", or the root zone. The names of the NS are specified
with this, so they have no explicit names and that's what the A records are
tied to.
For the NS record it says that it belongs to the zone with name "@", or
root (the "owner" field, on the left hand side), and the name of the NS for
that zone is also @, which from above is what owns the A records.


It might be easier to understand if you give the NS a name, such as:
myroots.mydomain.  A   X.Y.Z.7
myroots.mydomain.  A   X.Y.Z.8

NOTE: The dot after "...mydomain" terminates the name (like "." in a
sentence) and prevents it from inheriting the name of the zone. In this
zone it doesn't matter because the zone is "", so there is nothing to
inherit. In any other zone, it matters.

Then the NS record would become either:
.  IN   NS   myroots.mydomain.
or
@  IN   NS   myroots.mydomain.

"." is more conventional and is an absolute representation of the root.
"@" works too, but is a relative reference to 'this zone we are in', which
just happens to be the root zone.

Compare this with how it's done in the Internet hints file:

.360  IN  NSA.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.  360  A 198.41.0.4
A.ROOT-SERVERS.NET.  360    2001:503:BA3E::2:30


Hope that helps.
Greg

On Mon, 1 Jul 2024 at 16:05, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:

> Greg, David,
>
>
>
> Another questions or two before I commit the changes to my hints file.
>
>
> I have only the two servers, this last line isn’t necessary? Or for that
> matter, possibly detrimental?
> If it is, its “dot” rather than “at”?
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400    IN NS @
>
>
>
> Thank you.
>
> Brian
>
>
>
> *From:* bind-users  * On Behalf Of *Cuttler,
> Brian R (HEALTH) via bind-users
> *Sent:* Wednesday, June 26, 2024 12:56 PM
> *To:* Greg Choules ; David Farje <
> davidabelfa...@gmail.com>
> *Cc:* bind-users ; Hefner, Joseph (HEALTH) <
> joseph.hef...@health.ny.gov>
> *Subject:* RE: rolling my own hints file
>
>
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.*
>
>
>
>
>
> Greg, David,
>
>
>
> Thanks, much easier than what I thought it would be.
>
> I have two “root” servers so I went with this format, allowing a round
> robin selection.
>
> Essentially this, sorry trying to be vague on the IPs.
>
>
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400IN NS @
>
>
>
> Server reloaded fine and I am able to resolve non-domain information.
> Is there a flag someplace in dig or nslookup to show what root server I’m
> hitting? I don’t see that in any of the named log files, I may need to add
> an ACL to log the traffic in a router to verify.
> Then again – my FW is not seeing queries to any of the normal root
> servers, so that is in fact a good sign.
>
>
>
> New root servers are managed by my parent organization and my manager
> asked me to send these queries through them. Wouldn’t be performing this
> exercise otherwise.
>
>
>
> Thank you – I think you’ve given me exactly what was needed.
>
>
>
> Brian
>
>
>
> *From:* Greg Choules 
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH) 
> *Cc:* bind-users 
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com. Learn
> why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.*
>
>
>
> Hi Brian.
>
> Yes, you can define your own hint zone and tell BIND to use it. The
> contents (I called the file "db.root" but the name is your choice) could be
> as simple as:
>
>
>
> @ 300 IN A 127.0.0.3
> @ 300 IN NS @
>
>
>
> which says for this zone (which will be called ".", coming next) the NS is
> the same name and its IP is 127.0.0.3, which happens to be another instance
> of BIND I have running. Your file would

Re: forward option in dns server

[Greg Choules via bind-users]

Correct.

On Fri, 28 Jun 2024, 12:54 Renzo Marengo,  wrote:

> Ok very veri interesting,and about this doubt?
>
> etc/resolv.conf in bind server is used only from client services ? E.g.
> ping tool
> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>
> Thanks again
>
> Il giorno ven 28 giu 2024 alle ore 13:10 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi again Renzo.
>>
>> In general, BIND (and other resolvers) make non-recursives (aka
>> iterative) queries to authoritative servers, such as the roots and others.
>>
>> - Clients (laptops etc.) make recursive queries to the DCs. If the DCs
>> know the answer they respond immediately; no forwarding needed.
>> - If the DCs don't (currently) know the answer, they make recursive
>> queries to BIND because that's what you have told them to do, using either
>> global or conditional forwarding. If BIND knows the answer it responds
>> immediately; no need to make queries into the Internet.
>> - If BIND doesn't (currently) know the answer it makes non-recursive
>> queries to anywhere it needs, to gather information to construct a response.
>> It is important to note that each of these is a separate DNS conversation.
>>
>> Does that help?
>>
>> Please get another server (and a test server) and upgrade them all to
>> current software.
>>
>> Cheers, Greg
>>
>> On Fri, 28 Jun 2024 at 11:58, Renzo Marengo 
>> wrote:
>>
>>> Hi Greg again! :)
>>>
>>> > 1) This should help you understand the difference between recursive
>>> and non-recursive queries.
>>> I read about recursive and iterative query but I think A.B.C.D server
>>> should be as recursive server for domain controllers, I ask myself the same
>>> question to root servers? Or Bind9 server should have to make iterative
>>> queries to root servers ?
>>>
>>> > I hope this server is behind a good firewall?
>>> Yes
>>>
>>> >Do you only have one BIND server?
>>> >I would recommend two at least, in case you need to take one down for
>>> maintenance or it fails for some reason.
>>> Yes only one server
>>>
>>> >> Your "allow-..." statements should look like this, with IP addresses,
>>> not domain names.
>>> Oh yes, this one was to explain you what servers I inserted into this
>>> list.
>>>
>>>
>>> I have another doubt, /etc/resolv.conf in bind server is used only from
>>> client services ? E.g. ping tool
>>> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>>>
>>>
>>>
>>>
>>>
>>> Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
>>> gregchoules+bindus...@googlemail.com> ha scritto:
>>>
>>>> Hi Renzo.
>>>> You're welcome.
>>>> 1) Correct. You don't need forwarding for a simple resolver. Take a
>>>> look at the meaning of the RD flag in the BIND protocol header. This should
>>>> help you understand the difference between recursive and non-recursive
>>>> queries.
>>>> 2) No. See 1)
>>>> 3) Yes. For a standard resolver facing the Internet you do not need a
>>>> hint zone.
>>>>
>>>> Some more thoughts occurred to me:
>>>> - I hope this server is behind a good firewall?
>>>> - Do you only have one BIND server? I would recommend two at least, in
>>>> case you need to take one down for maintenance or it fails for some reason.
>>>> - Your "allow-..." statements should look like this, with IP addresses,
>>>> not domain names.
>>>>allow-... {127.0.0.1; ;
>>>> ; ;}; You do
>>>> not need to include this server in the list.
>>>>
>>>> Any changes you make should be done on a test server first, so you can
>>>> be comfortable understanding what effect those changes have and only move
>>>> them to production when you are certain.
>>>>
>>>> Cheers, Greg
>>>>
>>>> On Fri, 28 Jun 2024 at 07:14, Renzo Marengo 
>>>> wrote:
>>>>
>>>>> Hi greg,
>>>>> I thank you again for your suggestions.
>>>>>
>>>>> >A.B.C.D is the address of this server?
>>>>> yes, It's the Bind server
>>>>>
>>>>> I read several documents about DNS architecture
>>>>>

Re: forward option in dns server

[Greg Choules via bind-users]

Hi again Renzo.

In general, BIND (and other resolvers) make non-recursives (aka iterative)
queries to authoritative servers, such as the roots and others.

- Clients (laptops etc.) make recursive queries to the DCs. If the DCs know
the answer they respond immediately; no forwarding needed.
- If the DCs don't (currently) know the answer, they make recursive queries
to BIND because that's what you have told them to do, using either global
or conditional forwarding. If BIND knows the answer it responds
immediately; no need to make queries into the Internet.
- If BIND doesn't (currently) know the answer it makes non-recursive
queries to anywhere it needs, to gather information to construct a response.
It is important to note that each of these is a separate DNS conversation.

Does that help?

Please get another server (and a test server) and upgrade them all to
current software.

Cheers, Greg

On Fri, 28 Jun 2024 at 11:58, Renzo Marengo  wrote:

> Hi Greg again! :)
>
> > 1) This should help you understand the difference between recursive and
> non-recursive queries.
> I read about recursive and iterative query but I think A.B.C.D server
> should be as recursive server for domain controllers, I ask myself the same
> question to root servers? Or Bind9 server should have to make iterative
> queries to root servers ?
>
> > I hope this server is behind a good firewall?
> Yes
>
> >Do you only have one BIND server?
> >I would recommend two at least, in case you need to take one down for
> maintenance or it fails for some reason.
> Yes only one server
>
> >> Your "allow-..." statements should look like this, with IP addresses,
> not domain names.
> Oh yes, this one was to explain you what servers I inserted into this
> list.
>
>
> I have another doubt, /etc/resolv.conf in bind server is used only from
> client services ? E.g. ping tool
> I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
>
>
>
>
>
> Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>> You're welcome.
>> 1) Correct. You don't need forwarding for a simple resolver. Take a look
>> at the meaning of the RD flag in the BIND protocol header. This should help
>> you understand the difference between recursive and non-recursive queries.
>> 2) No. See 1)
>> 3) Yes. For a standard resolver facing the Internet you do not need a
>> hint zone.
>>
>> Some more thoughts occurred to me:
>> - I hope this server is behind a good firewall?
>> - Do you only have one BIND server? I would recommend two at least, in
>> case you need to take one down for maintenance or it fails for some reason.
>> - Your "allow-..." statements should look like this, with IP addresses,
>> not domain names.
>>allow-... {127.0.0.1; ;
>> ; ;}; You do
>> not need to include this server in the list.
>>
>> Any changes you make should be done on a test server first, so you can be
>> comfortable understanding what effect those changes have and only move them
>> to production when you are certain.
>>
>> Cheers, Greg
>>
>> On Fri, 28 Jun 2024 at 07:14, Renzo Marengo 
>> wrote:
>>
>>> Hi greg,
>>> I thank you again for your suggestions.
>>>
>>> >A.B.C.D is the address of this server?
>>> yes, It's the Bind server
>>>
>>> I read several documents about DNS architecture
>>> My questions is about this configuration of bind:
>>>
>>> 1- according to your opinion my bind makes queries ro root server if is
>>> set no 'forwarders' option? I'll verify It by tcpdump as you suggested
>>> 2- Do you suggest to set some "forwarders" ?
>>> 3-- This bind version has root server built-in? If I removed 'named.ca'
>>> reference, Bind would use root server built-in?
>>>
>>> thanks
>>>
>>> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
>>> gregchoules+bindus...@googlemail.com> ha scritto:
>>>
>>>> Hi Renzo.
>>>>
>>>> Thank you for that. The hints look OK. A bit old, but they will work.
>>>>
>>>> The first thing I would advise you to do as a matter of priority is to
>>>> upgrade BIND.
>>>> 9.11 has been end-of-life for a few years and there have been many
>>>> security fixes since then. 9.18.27 is the current version.
>>>> You could install that directly, or upgrade RHEL and obtain a more
>>>> recent packaged version.
>>>>
>

Re: forward option in dns server

[Greg Choules via bind-users]

Hi Renzo.
You're welcome.
1) Correct. You don't need forwarding for a simple resolver. Take a look at
the meaning of the RD flag in the BIND protocol header. This should help
you understand the difference between recursive and non-recursive queries.
2) No. See 1)
3) Yes. For a standard resolver facing the Internet you do not need a hint
zone.

Some more thoughts occurred to me:
- I hope this server is behind a good firewall?
- Do you only have one BIND server? I would recommend two at least, in case
you need to take one down for maintenance or it fails for some reason.
- Your "allow-..." statements should look like this, with IP addresses, not
domain names.
   allow-... {127.0.0.1; ;
; ;}; You do
not need to include this server in the list.

Any changes you make should be done on a test server first, so you can be
comfortable understanding what effect those changes have and only move them
to production when you are certain.

Cheers, Greg

On Fri, 28 Jun 2024 at 07:14, Renzo Marengo  wrote:

> Hi greg,
> I thank you again for your suggestions.
>
> >A.B.C.D is the address of this server?
> yes, It's the Bind server
>
> I read several documents about DNS architecture
> My questions is about this configuration of bind:
>
> 1- according to your opinion my bind makes queries ro root server if is
> set no 'forwarders' option? I'll verify It by tcpdump as you suggested
> 2- Do you suggest to set some "forwarders" ?
> 3-- This bind version has root server built-in? If I removed 'named.ca'
> reference, Bind would use root server built-in?
>
> thanks
>
> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>>
>> Thank you for that. The hints look OK. A bit old, but they will work.
>>
>> The first thing I would advise you to do as a matter of priority is to
>> upgrade BIND.
>> 9.11 has been end-of-life for a few years and there have been many
>> security fixes since then. 9.18.27 is the current version.
>> You could install that directly, or upgrade RHEL and obtain a more recent
>> packaged version.
>>
>>
>> You can check what BIND is doing by using "tcpdump". For example:
>> sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.D
>>
>> I am making some assumptions:
>> A.B.C.D is the address of this server?
>>  is the name of the interface the server will use for outbound
>> queries, according to its routeing table. I am guessing this is the
>> interface with address A.B.C.D?
>> -c stops the capture after 1000 packets. This is just a safety precaution.
>> port 53 and host A.B.C.D limits the capture to only packets with port 53
>> (DNS) AND with the address of this interface, so you don't capture any SSH
>> or HTTPS etc.
>>
>> A fresh (recently restarted) DNS resolver - any one, not just BIND - will
>> make queries to the root to start with. It does this to learn where to go
>> next. It stores the results of those queries in its cache so that it
>> doesn't have to make them again for some time.
>>
>> There are many good books and articles available online to explain the
>> basics of DNS. The BIND ARM (distributed with BIND and also available
>> online) is the reference manual for BIND itself.
>>
>> I hope that helps.
>> Greg
>>
>> On Fri, 28 Jun 2024 at 05:57, Renzo Marengo 
>> wrote:
>>
>>> Hi Greg,
>>> he info you required:
>>>
>>> 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version)
>>> on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
>>> 2) named.ca if file which contains root servers
>>> named.ca
>>> 
>>> .   518400  IN  NS  a.root-servers.net.
>>> .   518400  IN  NS  b.root-servers.net.
>>> .   518400  IN  NS  c.root-servers.net.
>>> .   518400  IN  NS  d.root-servers.net.
>>> .   518400  IN  NS  e.root-servers.net.
>>> .   518400  IN  NS  f.root-servers.net.
>>> .   518400  IN  NS  g.root-servers.net.
>>> .   518400  IN  NS  h.root-servers.net.
>>> .   518400  IN  NS  i.root-servers.net.
>>> .   518400  IN  NS  j.root-servers.net.
>>> .   518400  IN  NS  k.root-servers.net.
>>> .   518400  IN  NS  l.root-servers.net.
>>

Re: forward option in dns server

[Greg Choules via bind-users]

Hi Renzo.

Thank you for that. The hints look OK. A bit old, but they will work.

The first thing I would advise you to do as a matter of priority is to
upgrade BIND.
9.11 has been end-of-life for a few years and there have been many security
fixes since then. 9.18.27 is the current version.
You could install that directly, or upgrade RHEL and obtain a more recent
packaged version.


You can check what BIND is doing by using "tcpdump". For example:
sudo tcpdump -n -i  -c 1000 port 53 and host A.B.C.D

I am making some assumptions:
A.B.C.D is the address of this server?
 is the name of the interface the server will use for outbound
queries, according to its routeing table. I am guessing this is the
interface with address A.B.C.D?
-c stops the capture after 1000 packets. This is just a safety precaution.
port 53 and host A.B.C.D limits the capture to only packets with port 53
(DNS) AND with the address of this interface, so you don't capture any SSH
or HTTPS etc.

A fresh (recently restarted) DNS resolver - any one, not just BIND - will
make queries to the root to start with. It does this to learn where to go
next. It stores the results of those queries in its cache so that it
doesn't have to make them again for some time.

There are many good books and articles available online to explain the
basics of DNS. The BIND ARM (distributed with BIND and also available
online) is the reference manual for BIND itself.

I hope that helps.
Greg

On Fri, 28 Jun 2024 at 05:57, Renzo Marengo  wrote:

> Hi Greg,
> he info you required:
>
> 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support Version)
> on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
> 2) named.ca if file which contains root servers
> named.ca
> 
> .   518400  IN  NS  a.root-servers.net.
> .   518400  IN  NS  b.root-servers.net.
> .   518400  IN  NS  c.root-servers.net.
> .   518400  IN  NS  d.root-servers.net.
> .   518400  IN  NS  e.root-servers.net.
> .   518400  IN  NS  f.root-servers.net.
> .   518400  IN  NS  g.root-servers.net.
> .   518400  IN  NS  h.root-servers.net.
> .   518400  IN  NS  i.root-servers.net.
> .   518400  IN  NS  j.root-servers.net.
> .   518400  IN  NS  k.root-servers.net.
> .   518400  IN  NS  l.root-servers.net.
> .   518400  IN  NS  m.root-servers.net.
>
> ;; ADDITIONAL SECTION:
> a.root-servers.net. 518400  IN  A   198.41.0.4
> b.root-servers.net. 518400  IN  A   199.9.14.201
> c.root-servers.net. 518400  IN  A   192.33.4.12
> d.root-servers.net. 518400  IN  A   199.7.91.13
> e.root-servers.net. 518400  IN  A   192.203.230.10
> f.root-servers.net. 518400  IN  A   192.5.5.241
> g.root-servers.net. 518400  IN  A   192.112.36.4
> h.root-servers.net. 518400  IN  A   198.97.190.53
> i.root-servers.net. 518400  IN  A   192.36.148.17
> j.root-servers.net. 518400  IN  A   192.58.128.30
> k.root-servers.net. 518400  IN  A   193.0.14.129
> l.root-servers.net. 518400  IN  A   199.7.83.42
> m.root-servers.net. 518400  IN  A   202.12.27.33
> a.root-servers.net. 518400  IN  2001:503:ba3e::2:30
> b.root-servers.net. 518400  IN  2001:500:200::b
> c.root-servers.net. 518400  IN  2001:500:2::c
> d.root-servers.net. 518400  IN  2001:500:2d::d
> e.root-servers.net. 518400  IN  2001:500:a8::e
> f.root-servers.net. 518400  IN  2001:500:2f::f
> g.root-servers.net. 518400  IN  2001:500:12::d0d
> h.root-servers.net. 518400  IN  2001:500:1::53
> i.root-servers.net. 518400  IN  2001:7fe::53
> j.root-servers.net. 518400  IN  2001:503:c27::2:30
> k.root-servers.net. 518400  IN  2001:7fd::1
> l.root-servers.net. 518400  IN  2001:500:9f::42
> m.root-servers.net. 518400  IN  2001:dc3::35
> 
>
> I didn't know some Bind versions had the Internet root hints built-in.
> About my configuration I understand that bind makes always queries to root
> servers ? Right?
> I'd like to re-check configuration of bind
>
>
> Il giorno gio 27 giu 2024 alle ore 22:15 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>> Ah OK, I had it the wrong way round. AD DNS needs to re

Re: forward option in dns server

[Greg Choules via bind-users]

Hi Renzo.
Ah OK, I had it the wrong way round. AD DNS needs to resolve names in the
Internet on behalf of its clients, so it forwards to BIND.

In that case, two questions:
1) What version of BIND are you running? You can get this with "named -V"
2) What is in the file "named.ca"?
For a long time (which is why I need to know the version) BIND has had the
Internet root hints built in, so you don't need a hint zone anymore. Unless
you are defining different roots for some reason. Hence why I need to know
the contents of that file.

Thanks, Greg



On Thu, 27 Jun 2024 at 18:06, Renzo Marengo  wrote:

>
> Hi Greg,
>
> thank you very much for your explanation.
>
> Let’s supposte AD domain was ‘my domain.it’  and I have 6000 computers of
> government institute.
>
> Here my bind configuration:
>
>
> named.conf
>
> ———
>
> include “…. named.conf.options" ;
>
> zone "." IN {
>
> type hint;
>
> file "named.ca";
>
> };
>
> include “…. named.rfc1912.zones";
>
> include “….  named.root.key";
>
> ———
>
>
>
> named.conf.options
>
> ———
>
> logging {
>
> channel named_debug {
>
> syslog local6;
>
> severity debug 1;
>
> print-category yes;
>
> print-severity yes;
>
> print-time yes;
>
> };
>
> category default { named_debug; };
>
> };
>
>
> options {
>
> auth-nxdomain no;# conform to RFC1035
>
> allow-recursion {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ;
>
> allow-query   {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ;
>
> recursive-clients 3000;
>
> allow-query-cache {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
> ….. } ; ;
>
>
> listen-on port 53 { 127.0.0.1; A.B.C.D; };
>
> directory “….. named";
>
> dump-file “….. cache_dump.db";
>
> statistics-file “….. named_stats.txt";
>
> memstatistics-file “…. named_mem_stats.txt";
>
> recursing-file  “… named.recursing";
>
> secroots-file   “… named.secroots";
>
> recursion yes;
>
> dnssec-enable no;
>
> dnssec-validation no;
>
>
> bindkeys-file "….. named.iscdlv.key";
>
> managed-keys-directory "….. dynamic";
>
> pid-file "….. named.pid";
>
> session-keyfile "….. session.key";
>
> ———
>
>
>
> >Thirdly, I would not forward to AD DNS, unless the AD servers also
> recurse and can provide >resolution for delegated names below the AD domain
>
> >that are not hosted on the AD servers themselves.
>
>
> There is no forward option to AD DNS. Forward is enable from AD DNS to
> A.B.C.D. bind9 server.
>
>
>
>
> All clients are using AD DNS infact every query, about name of ‘
> mydomain.it,’ is resolved from AD DNS.
>
> When client asks an external domain, e.g. www.google.it, AD server
> forward query to A.B.C.D. server. (Forward option is set on every domain
> controller)
>
> Only AD DNS  make queries to A.B.C.D server and it’s necessary only to
> solve external domains.
>
> A.B.C.D. server never makes queries to AD server. A.B.C.D. is next dns
> server which partecipates when it’s necessary to resolve an external domain
>
>
> I hope to have explained right.
>
> I thought A.B.C.D server made query to root server because into
> configuration there is no reference to forward option, because I thought to
> set as DNS forward a government dns of my country. What do you think?
>
> I have doubts about recursive and iterative queries options too.
>
> Thanks
>
>
> Il giorno gio 27 giu 2024 alle ore 13:24 Greg Choules <
> gregchoules+bindus...@googlemail.com> ha scritto:
>
>> Hi Renzo.
>> Firstly, please can we see your BIND configuration and have the actual AD
>> domain name.
>>
>> Secondly, BIND, or any other recursive DNS server, does not 'forward' to
>> the root servers, unless you have configured it explicitly to do so, which
>> would be a bad idea and not work anyway. It will recurse (paradoxically,
>> perform non-recursive aka iterative queries) to the roots and other
>> authoritative servers. It is an important distinction to be aware of.
>>
>> Thirdly, I would not forward to AD DNS, unless the AD servers also
>> recurse and can provide resolution for delegated names below the AD domain
>> that are not hosted on the AD servers themselves. Personally I would use a
>> stub or static-stub zone in BIND to refer to the AD domain.
>>

Re: forward option in dns server

[Greg Choules via bind-users]

Hi Renzo.
Firstly, please can we see your BIND configuration and have the actual AD
domain name.

Secondly, BIND, or any other recursive DNS server, does not 'forward' to
the root servers, unless you have configured it explicitly to do so, which
would be a bad idea and not work anyway. It will recurse (paradoxically,
perform non-recursive aka iterative queries) to the roots and other
authoritative servers. It is an important distinction to be aware of.

Thirdly, I would not forward to AD DNS, unless the AD servers also recurse
and can provide resolution for delegated names below the AD domain that are
not hosted on the AD servers themselves. Personally I would use a stub or
static-stub zone in BIND to refer to the AD domain.

In general, decide which DNS is going to do the resolving and make that the
control point, fetching data from wherever it needs to (e.g. AD DNS) -
using non-recursive queries - and using that data to construct answers for
its clients.

I hope that helps.
Cheers, Greg

On Thu, 27 Jun 2024 at 12:02, Renzo Marengo  wrote:

> I have Active Directory domain ( 'mydomain.it' ) with 8 domain
> controllers to manage 8000 computers. Every Domain controller acts as dns
> service and resolve internal domain names while forward queries about
> external domains to another server, which Bind9 dns server (It's inside my
> company)
> I'm checking this Bind9 configuration (Centos server) and I see no forward
> servers so I think It makes bind9 forward queries directly to root servers.
> What do you think ?
> According your opinion this Bind9 server should have to forward requests
> to one or more dns server by forward option?
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: rolling my own hints file

[Greg Choules via bind-users]

Hi Brian.
Ni problem. The server may tell the client (dig; please not nslookup)
information about where the answer came from, if 'minimal-responses' is set
to "no". Usually clients don't need to know that, so please take a look at
how m-r works:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-minimal-responses

Cheers, Greg

On Wed, 26 Jun 2024 at 17:55, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:

>
>
> Greg, David,
>
>
>
> Thanks, much easier than what I thought it would be.
>
> I have two “root” servers so I went with this format, allowing a round
> robin selection.
>
> Essentially this, sorry trying to be vague on the IPs.
>
>
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400IN NS @
>
>
>
> Server reloaded fine and I am able to resolve non-domain information.
> Is there a flag someplace in dig or nslookup to show what root server I’m
> hitting? I don’t see that in any of the named log files, I may need to add
> an ACL to log the traffic in a router to verify.
> Then again – my FW is not seeing queries to any of the normal root
> servers, so that is in fact a good sign.
>
>
>
> New root servers are managed by my parent organization and my manager
> asked me to send these queries through them. Wouldn’t be performing this
> exercise otherwise.
>
>
>
> Thank you – I think you’ve given me exactly what was needed.
>
>
>
> Brian
>
>
>
> *From:* Greg Choules 
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH) 
> *Cc:* bind-users 
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com. Learn
> why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.*
>
>
>
> Hi Brian.
>
> Yes, you can define your own hint zone and tell BIND to use it. The
> contents (I called the file "db.root" but the name is your choice) could be
> as simple as:
>
>
>
> @ 300 IN A 127.0.0.3
> @ 300 IN NS @
>
>
>
> which says for this zone (which will be called ".", coming next) the NS is
> the same name and its IP is 127.0.0.3, which happens to be another instance
> of BIND I have running. Your file would contain the names and IPs of your
> internal roots.
>
>
>
> In the config, define the hint zone like this:
>
>
>
> zone "." {
> type hint;
> file "db.root";
> };
>
>
>
> That should be all you need.
>
> Cheers, Greg
>
>
>
> On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
> bind-users@lists.isc.org> wrote:
>
> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400  IN  A   198.41.0.4
>
> b.root-servers.net. 518400  IN  A   170.247.170.2
>
> c.root-servers.net. 518400  IN  A   192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: rolling my own hints file

[Greg Choules via bind-users]

Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The
contents (I called the file "db.root" but the name is your choice) could be
as simple as:

@ 300 IN A 127.0.0.3
@ 300 IN NS @

which says for this zone (which will be called ".", coming next) the NS is
the same name and its IP is 127.0.0.3, which happens to be another instance
of BIND I have running. Your file would contain the names and IPs of your
internal roots.

In the config, define the hint zone like this:

zone "." {
type hint;
file "db.root";
};

That should be all you need.
Cheers, Greg

On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
bind-users@lists.isc.org> wrote:

> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400  IN  A   198.41.0.4
>
> b.root-servers.net. 518400  IN  A   170.247.170.2
>
> c.root-servers.net. 518400  IN  A   192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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 error during the evening

[Greg Choules via bind-users]

Hi Sami.
If you can, I would set up a new BIND (test) server running the current
code - 9.18.27 - next to your current production system and compare how
they behave: current code uses NS queries for qmin rather than _... A
queries. There may still be failures, but this would allow you to pinpoint
better which domains are the problematic ones.
Packet captures are always good for showing exactly what servers send and
what they get back. There's no hiding in Wireshark!

Cheers, Greg

On Wed, 26 Jun 2024 at 07:45,  wrote:

> Hello
> Thank you for your response. I have configured qname to disabled for now.
> Once the issue is resolved, I will set it to relaxed. I have provided a
> download link for the log files and a dig +trace test for more details on
> this issue, which I do not think is related to BIND or its configuration. I
> suspected that a firewall was blocking the DNS traffic, so I bypassed the
> firewall, but the result is the same. How can we ensure that this is a
> network-level issue?
>
> download link:
>
> https://we.tl/t-M77os84duE
>
> Regards
>
> Sami
>
> -Message d'origine-
> De : bind-users  De la part de
> bind-users-requ...@lists.isc.org
> Envoyé : mardi 25 juin 2024 13:00
> À : bind-users@lists.isc.org
> Objet : bind-users Digest, Vol 4495, Issue 2
>
>
> --
> CAUTION : This email originated outside the company. Do not click on any
> links or open attachments unless you are expecting them from the sender.
>
> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez
> pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre
> l'expéditeur.
>
> --
>
> 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. Re: SERVFAIL error during the evening (Michael Batchelder)
>2. Re: qname minimization: me too :( (Stephane Bortzmeyer)
>3. Re: can I provide invalid HTTPS values for testing?
>   (Stephane Bortzmeyer)
>
>
> --
>
> Message: 1
> Date: Tue, 25 Jun 2024 06:34:42 + (UTC)
> From: Michael Batchelder 
> To: bind-users 
> Cc: sami rahal 
> Subject: Re: SERVFAIL error during the evening
> Message-ID: <646819319.2383375.1719297282567.javamail.zim...@isc.org>
> Content-Type: text/plain; charset=utf-8
>
> >> Hello Michael
> >> Thank you for your response. Here is a pcap file and some logs.
> >
> > Hello Sami,
> >
> > Your pcap shows your resolver making thousands of queries that get no
> > responses (or at least the pcap does not contain them). There's not
> > much I can say, beyond that this does not appear to be a > problem
> > related to BIND.
>
> Sami,
>
> My co-worker helpfully pointed out something I missed when reviewing your
> packet capture. A large number of your resolution failures are because your
> BIND is configured to use QNAME minimization (a.k.a. "qmin") and the
> queries are to zones whose configuration is done incorrectly and breaks
> qmin.
>
> The pcap indicates you have the 'qname-minimization strict' setting in
> your BIND configuration file. See the "qname-minimization" statement in the
> Options section of the BIND ARM (
> https://bind9.readthedocs.io/en/v9.16.25/reference.html#options-statement-definition-and-usage).
> For the general background on qmin, read RFCs 7816 and 9156.
>
> I don't know of a reason why you would experience more qmin failures in
> the evening, other than the requests that fail are only made at that time.
> Regardless, if you want to stop the failures completely, you can change the
> 'qname-minimization strict' setting to 'qname-minimization disabled'. The
> drawback is that your queries will no longer be minimized, so all
> authoritative servers will see the full query name during recursion.
>
> As a compromise between doing nothing and fully disabling qmin, you can
> use the &#x

Re: Problem with a certain domain

[Greg Choules via bind-users]

Hi Thomas.
Firstly, I doubt you actually need to kill and restart `named`. Flushing
the cache would probably work, either all of it or just selected names.

Secondly, take a packet capture of this happening and analyse what BIND is
really doing, in Wireshark.
- If it shows up that certain NS are causing the problem you can avoid
them, in config.
- If it's a DNSSEC issue, you can get around that on a per-domain basis, if
needed.
- If it turns out that qname minimization is the issue, you can play with
settings for that, too.

In short, there are plenty of tools in the kit bag. But understand what the
problem is first and to do that, gather data (pcaps and logs) that can be
used to paint a picture of what's really happening.

Cheers, Greg

On Tue, 4 Jun 2024 at 13:01, Thomas Barth via bind-users <
bind-users@lists.isc.org> wrote:

> Am 2024-06-04 09:50, schrieb Matus UHLAR - fantomas:
> > On 03.06.24 18:46, Thomas Barth via bind-users wrote:
> >> Should I perhaps ask the mail user to unsubscribe from this website
> >> due to troubles of bad configuration?
> >
> >
> > yeah I guess you should, their DNS servers are pretty much messed up:
>
> A temporary solution :-)
>
> /etc/postfix/access-sender
> newsletter.mallorcazeitung.es 550 Please configure your ns correctly
> [...]
>
> So, what I still don't understand is why it works on one server and not
> on the other. And this depends on which network the server is on? Bind
> is configured the same on all my servers. Shouldn't Bind then be
> confronted with the problem on all servers? How do I get a really
> uniform configuration?
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: issue with forwarder zones

[Greg Choules via bind-users]

Hi Brian.
We're going to need some details please, like for starters:
- What's the domain being queried?
- A network diagram showing where your BIND server is and what it's
forwarding to.
- IP addresses of everything.
- A packet capture (binary pcap format, not a snippet or a screenshot) from
your BIND server showing both client->server and server->forwarder DNS
traffic, crucially capturing the moment this issue occurs.
- dig results from your making test queries.

It may sound like a lot of detail, but the devil... as they say.

Cheers, Greg


On Wed, 29 May 2024 at 21:48, Cuttler, Brian R (HEALTH) via bind-users <
bind-users@lists.isc.org> wrote:

> My bad - I'd mailed this mistakenly to an individual and not the list.
>
> ---
>
> I am currently running BIND 9.18.18-0ubuntu0.22.04.2-Ubuntu.
>
> I am sometimes seeing that I don't have resolution for some FQDN in
> forwarder zones.
>
> Usually it works, sometimes I don't get resolution. Interesting I failed
> resolution for an FQDN yesterday and while relieved to see that I failed to
> get resolution on the authoritative server I later was able to resolve on
> the authoritative server but still failed on the local forwarding server.
>
> Wondering what is going on there.
>
> Conjecture - caching the failed response for some period of time?
> If so, disable caching for the problematic forwarder zone?
>
> Some other issue? If so what might it be, how can I test for it and how do
> I resolve/work-around it?
>
> Thanks in advance,
> Brian
>
>
> Brian R Cuttler
> System and Network Administrator
> Wadsworth Center, New York State Department of Health
> Empire State Plaza
> Corning Tower, Sublevel D-280, Albany NY 12237
> 518 486-1697 (O)
> 518 redacted (C)
> brian.cutt...@health.ny.gov
> https://www.wadsworth.org
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Make dig and nslookup DNSSEC aware?

[Greg Choules]

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

Cheers, Greg

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

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

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


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

Re: SRV on multiple subdomains

[Greg Choules via bind-users]

Adding my 2p, I would take that principle a step further.
Create a generic, unique SRV record that represents what you want to
happen. Then create specific CNAME records for each server. The reasons for
the extra, generic record are that it represents the service you want to
offer and all "server.." records you want to use that service are identical
in structure. e.g.

imap-tcp-service.example.com.  SRV  
_imap._tcp.server1.example.com.  CNAME  imap-tcp-service.example.com.
_imap._tcp.server2.example.com.  CNAME  imap-tcp-service.example.com.
...
_imap._tcp.server999.example.com.  CNAME  imap-tcp-service.example.com.
and so on.

Cheers, Greg

On Thu, 16 May 2024 at 11:43, Niall O'Reilly  wrote:

> On 14 May 2024, at 15:20, DEMBLANS Mathieu wrote:
>
> A part of the subdomains are managed by us, others subdomains by an other
> entity.
> So we can't configure a generic target for all subdomains as each entity
> has its own target for SRV entries.
>
> -Message d'origine-
>
> De : bind-users bind-users-boun...@lists.isc.org De la part de Matus
> UHLAR - fantoms
> Envoyé : mardi 14 mai 2024 15:58
> À : bind-users@lists.isc.org
> Objet : Re: SRV on multiple subdomains
> On 14.05.24 13:08, DEMBLANS Mathieu wrote:
>
> I have a question about configuration simplification for SRV configuration
> (maybe it can be applyed for other entries).
>
> We manage multiple subdomain of a main one (server1.example.com,
> server2.example.com,...).
> For A and MX entries, we use a general domain definitions with wildcard
> but is there a way to do so for SRV without having to define all subdomains
> (we have several dizains of it) ?
>
> We have to define some SRV entries with the same target like :
> _imap._tcp.server1.example.com IN SRV main.exemple.com
> _imap._tcp.server2.example.com IN SRV main.exemple.com
>
> Since a record is needed for each host, I think I would use something like
> this:
>
> imap._tcp.server1.example.com. IN SRV main.example.com.
> imap._tcp.server2.example.com. IN CNAME imap._tcp.server1.example.com.
> ...
> imap._tcp.servern.example.com. IN CNAME imap._tcp.server1.example.com.
>
> The advantage here is that, if ever the target of the SRV record had to
> be changed, only one record would have to be updated.
>
> /Niall
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: [help]how to configure ecs subnet for bind-9.18-21

[Greg Choules]

OK.

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

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

I hope that helps.
Greg

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

> 
> 
>   
> Yang
> 395096...@qq.com
>  
> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=Yang&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287&mail=395096713%40qq.com&code=>
>  
> 
> 
> -- Original --
> From: "Greg Choules" ;
> Date: Sun, Apr 28, 2024 03:39 PM
> To: "Yang"<395096...@qq.com>;
> Cc: "bind-users";
> Subject: Re: [help]how to configure ecs subnet for bind-9.18-21
> 
> Hello.
> Do you mean 9.18-S1?
> 
> 
>> On 28 Apr 2024, at 08:06, Yang via bind-users  
>> wrote:
>> 
>> 
>> dear admin:
>>   now, i use bind-9.18-21, i want to use ecs client subnet function; but i 
>> don't know how to configure it, and i don't get method from google
>>   please give me some example,or document , or google links to learn about 
>> it ;
>>   thanks!
>>  
>> Yang
>> 395096...@qq.com
>>  
>> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=Yang&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fg%3Fb%3Dsdk%26k%3DQCkTfUibqnEM6qRuG2lPLNA%26s%3D100%26t%3D1556340979%3Frand%3D1639145287&mail=395096713%40qq.com&code=>--
>>  
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
>> this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 

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

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


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

Re: [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: RFC8482: Implementation

[Greg Choules via bind-users]

Hi.
In BIND, since 9.11, there is an option/view statement called
"minimal-any", which defaults to "no". That might be what you're after.

Cheers, Greg

On Sat, 20 Apr 2024 at 17:29, Amaury Van Pevenaeyge <
avanpevenae...@outlook.fr> wrote:

> Hello everyone,
>
> I've been looking for days and days for a way to implement the principle
> documented in RFC8482 (Providing Minimal-Sized Responses to DNS Queries
> That Have QTYPE=ANY) as Cloudflare is currently doing. I can't find the
> solution to do this. Can anyone help me with this?
>
> 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: Some Authoritative-Only BCPs

[Greg Choules via bind-users]

Hi Crist.
Firstly, DNS servers do not make recursive queries, unless they have been
configured to forward.
Secondly, please start a packet capture on your server (save to disc, so
you can analyse it later in Wireshark) then start BIND and make some test
queries to your server. Look at what your server is doing as it starts and
as you make queries to it. It *will* need Internet access and you should
permit this in your firewall - port 53, both UDP and TCP.

As for the question of DNSSEC validation - yes or no? There is more DNSSEC
around these days than there used to be and choosing to NOT do validation
will hurt you in future, or maybe even right now. My advice would be to
enable it, look at packet captures, ask questions and understand it, rather
than disable it because you don't think you need it.

Cheers, Greg.

On Sun, 31 Mar 2024 at 08:07, Crist Clark  wrote:

> Thanks so much for the response.
>
> This machine does not have any reasons to do recursive queries to
> the Internet, and it is not allowed in the firewall.
>
> Looks like the article quoted is the guidance I was looking for. This
> server has "notify no", AND all of the name servers are in the
> authoritative
> zones anyway. And it has no need to ever do DNSSEC validation. I wonder
> if
> the traffic I was seeing was solely due to trust anchor maintenance. If
> I
> turn off dnssec-validation, will that traffic go away without having to
> become master for root? I'll give that a try.
>
> None of the other cases in the article apply. All zones are "secondary"
> (except the fake root if I need to keep that). The DNSSEC arguments seem
> kind of circular. You need to allow recursive behavior to support
> DNSSEC,
> and DNSSEC is needed to support recursive behavior.
>
> Interesting that you bring up the case of non-Internet root. We do have
> networks like that too. The authoritative-only DNS servers there should
> have analogous configuration. We shouldn't need to put that network's
> root in the authoritative-only servers or enable DNSSEC...
>
> Although this did remind me of one reason to enable dnssec-validation
> for totally non-technical reasons. Compliance. For when the auditors
> come
> around. It's easier to just have dnssec-validation enabled rather than
> deal
> with getting security exceptions or adverse findings. It's
> (unfortunately)
> a _really_ good reason to enable it even if it is technically
> unnecessary.
>
>
> On 2024-03-28 01:04, Greg Choules wrote:
> > Hi cjc.
> > My answers would be:
> >
> > - Leave `dnssec-validation` alone (auto) and ensure your server has a
> > path
> > to the Internet to make queries.
> >
> > - Don't mess with root hints. The only time anyone should need to do
> > this
> > is when running a completely captive server living in a custom
> > namespace
> > that is NOT the Internet.
> >
> > - I don't know if "none" and "!all" work out to be the same thing in
> > code
> > terms, but my preference would be "none" anyway because 1) that's
> > what's in
> > the documentation and would be the obvious choice, and 2) why
> > deliberately
> > create a negated expression that is harder to parse, mentally? Glancing
> > through a config and seeing "...!all..." you may not notice the "!" and
> > just see the "all". Even if you do see the pling, a statement
> > containing it
> > reads something like "I would like to permit not all", which requires
> > some
> > thinking about the intent. Whereas "I would like to permit none" (for
> > me
> > anyway) is clearer and less ambiguous.
> >
> > As for why authoritative servers need to make queries at all, please
> > take a
> > look at this article.
> >
> https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries
> >
> > Hope that helps.
> > Greg
> >
> > On Thu, 28 Mar 2024 at 06:15, Crist Clark 
> > wrote:
> >
> >> I am upgrading and redeploying some authoritative-only BIND servers.
> >> Two
> >> questions about some fine points:
> >>
> >> What to set 'dnssec-validation'? Just let it default to 'auto?' There
> >> is
> >> no need or opportunity for an authoritative-only server to validate
> >> (right?). Should we actively switch it off, set it to 'no?' For
> >> example,
> >> does setting it to 'no' reduce any resource use or reduce the security
> >> vulnerability space?
> >>
> >> This is bordering 

Re: Some Authoritative-Only BCPs

[Greg Choules via bind-users]

Hi cjc.
My answers would be:

- Leave `dnssec-validation` alone (auto) and ensure your server has a path
to the Internet to make queries.

- Don't mess with root hints. The only time anyone should need to do this
is when running a completely captive server living in a custom namespace
that is NOT the Internet.

- I don't know if "none" and "!all" work out to be the same thing in code
terms, but my preference would be "none" anyway because 1) that's what's in
the documentation and would be the obvious choice, and 2) why deliberately
create a negated expression that is harder to parse, mentally? Glancing
through a config and seeing "...!all..." you may not notice the "!" and
just see the "all". Even if you do see the pling, a statement containing it
reads something like "I would like to permit not all", which requires some
thinking about the intent. Whereas "I would like to permit none" (for me
anyway) is clearer and less ambiguous.

As for why authoritative servers need to make queries at all, please take a
look at this article.
https://kb.isc.org/docs/why-does-my-authoritative-server-make-recursive-queries

Hope that helps.
Greg

On Thu, 28 Mar 2024 at 06:15, Crist Clark  wrote:

> I am upgrading and redeploying some authoritative-only BIND servers. Two
> questions about some fine points:
>
> What to set 'dnssec-validation'? Just let it default to 'auto?' There is
> no need or opportunity for an authoritative-only server to validate
> (right?). Should we actively switch it off, set it to 'no?' For example,
> does setting it to 'no' reduce any resource use or reduce the security
> vulnerability space?
>
> This is bordering on aesthetic (maybe the first one is too), but what to
> do about the compiled-in root hints? Even on my authoritative-only server
> with "recursion no," every forty-five minutes or so, it's trying to go to
> the root servers and retrieve the NS and DNSKEY RRs for the root. It's
> blocked since there is no reason for this server to do outbound DNS, except
> to its hidden masters, so it just keeps trying and cluttering the firewall
> logs. What's the best way to stop this behavior? Is there a configuration
> option? I did this,
>
> zone "." {
> type primary;
> file "primary/empty-zone.db";
> allow-query { none; };
> };
>
> Which seems to do the trick, but is that the cleanest way? Any problems
> with that approach that I haven't considered?
>
> Oh, one final bonus question, is there any difference between specifying
> 'none' and '!all' in a server list, ACL, etc.? I prefer 'none', but the old
> configurations used '!all'. Can I change those without worrying?
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: transfert master slave

[Greg Choules via bind-users]

Hi Sami.
"allow-..." statements are to restrict from which sources *this* server
will accept messages, of whichever type.
On the secondary (slave), "allow-notify {192.168.56.154;};" will permit it
to process NOTIFY messages sent to it from the primary (master), but ignore
any others. Actually, this is not necessary because it would do that
anyway. See the ARM description for this statement -
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify

NOTIFY messages from the primary will reach the secondary server and be
processed because the primary is listed in an NS record in the zone. As
Mark says, you cannot stop this. You could test sending NOTIFY from a third
server that is *not* listed as an NS for the zone.

On the primary you do not need allow-transfer {192.168.56.157;}; as the
primary is not transferring *from* the secondary.
You probably also don't need also-notify {192.168.56.157;}; if the
secondary has an NS record in the zones it will be transferring, which it
should.

Hope that helps.
Greg

On Mon, 25 Mar 2024 at 11:34,  wrote:

> Hello community,
>
> I'm trying to configure a DNS slave server (192.168.56.157) . I want to
> allow notifications only from the master (192.168.56.154). I added the
> directive "allow-notify {192.168.56.154;};" and it works. However, when I
> try to test the prohibition of notification by adding "allow-notify
> {none;};" at the slave, it still receives updates from the master. The
> transfer on the master is as follows:
>
> allow-transfer {192.168.56.157;};
>
> also-notify {192.168.56.157;};
>
> notify explicit;"
>
>
>
> PS. BIND version : 9.16.48
>
>
>
> Regards Sami
>
> Orange Restricted
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: DNSSEC deployement in an isolated virtual environment

[Greg Choules via bind-users]

Hi Amaury.
You should be able to do this by defining your own trust anchors. This
should explain what you need:
https://bind9.readthedocs.io/en/latest/dnssec-guide.html#trusted-keys-and-managed-keys

Have fun.
Greg

On Sat, 16 Mar 2024 at 13:38, Amaury Van Pevenaeyge <
avanpevenae...@outlook.fr> wrote:

> Hello I'm a student in my last year of the Master in Cybersecurity at ULB.
> As part of my thesis, I'm doing research to develop a DNS Amplification
> scenario that will eventually be deployed within a Cyber Range. I have to
> carry out various measurements and develop different attacks in a virtual
> environment. I've already been able to set up my entire environment in
> VirtualBox for DNS (i.e. without DNSSEC). Now I need to deploy DNSSEC on my
> server. I've managed to generate my key pairs and sign my DNS zones.
> However, when I try to do a dig from my client VM, I get a SERVFAIL. I
> think this is because the chain of trust can't be established, which in my
> case is perfectly normal as I'm in an isolated test environment. So how can
> I deploy DNSSEC correctly so that the chain of trust is not taken into
> account and it works in my virtual environment? I think I know how DNSSEC
> works, but if you also have any clarification to offer, I'd be delighted to
> hear from you. My BIND server runs on an Ubuntu22.04 Jammy Jellyfish VM.
>
> Thanks in advance for your help.
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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 "split zones"

[Greg Choules via bind-users]

Hi.
If I understand you correctly, you are trying to get your resolver to go to
two different places (main_hidden_dns_server and other_dns_server) for
answers to the same question, and then want it combine those answers into a
single response to the client, which contains PTR records for both names?

If I got that correct, then it won't. If you want multiple PTR records to
be associated with different names then they have to be in the same
zone/zone file.

A few comments:
- The statement "forward first' means, try forwarding first and only if
that fails, then try recursion.
- Adding forwarders to a secondary zone tells the server what to do for
names delegated from that zone. e.g. if the zone is "example.com" and it
contains "sub NS another.server.somewhere.else." then a query to it for "
name.sub.example.com" will follow the "forwarders" statement because "
sub.example.com" has been delegated away.
- Do you really want to be forwarding to your hidden primary anyway?
- Why are two different servers both authoritative for
"100.168.192.in-addr.arpa"? That's asking for trouble.

Hope that helps.
Greg

On Mon, 4 Mar 2024 at 15:35, Taavi Ansper via bind-users <
bind-users@lists.isc.org> wrote:

> Hi
>
> I am trying to understand bind9 more thorughly.
>
> Backstory: We have been using bind9 for a long time and overhauling it
> for more "usage".
>
> We have been using a "hidden master dns" logic with views for different
> usages.
>
> E.g. Client -> Slave DNS Server <- (Transfer zones from hidden master)->
> Hidden Master.
>
> We had two views "external" and "internal" and now we added a new view
> "dmz" aswell.
>
> In one of those zones we had an interesting DNS "thingy" where for
> example a CIDR 192.168.100.0/24 was generating entries to the main
> "hidden dns" server via includes. It uses a domain called example.com.
> Now another DNS server created DNS entries for the same CIDR
> 192.168.100.0/24 but it had a different domain "subdomain.example.com".
> Including that info was easy.
>
> In the Slave DNS
>
> zone "example.com" {
>  file blaah
>  type slave
>  masters { main_hidden_dns_server }
> }
>
> zone "subdomain.example.com" {
>  file blaah
>  type slave;
>  masters { other_dns_server }
> }
>
> But now comes the problem. When generating a PTR record
> 100.168.192.in-addr.arpa, I wish to combine both of these "results" into
> one lookup. How can I do that? I tried to add:
>
> zone "100.168.192.in-addr.arpa" {
>  file blaah
>  type slave;
>  masters { other_dns_server }
>  forward first;
>  forwarders {  main_hidden_dns_server }
> }
>
> But this forwarding logic doesnt work. I have a feeling the forwarding
> only works specific zones.  and you can't combine two of the same
> "names" into one. Am I correct and in order for PTR records to work I
> need to get them into a single file?
>
> --
> 
> Taavi Ansper
> taavi.ans...@cyber.ee
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: fixed rrset ordering - is this still a thing?

[Greg Choules via bind-users]

Please don't encourage using "search" in resolv.conf or the Windows
equivalent. Search domains make queries take longer, impose unnecessary
load on resolvers and make diagnosis of issues harder because, when users
say "it doesn't work" you have no idea what it was that didn't work.

I tried using separate subdomains for different interfaces on devices once
and ran into exactly that problem. There's also the overhead of maintaining
more zones than you really need.

My suggestion would be to replace the dot with a hyphen. That is, instead
of:
firewall1.example.com = Internet IP address
firewall1.dmz.example.com = IP address on DMZ network
firewall1.management.example.com = IP address on out-of-band management
network

do:

firewall1-internet.example.com = Internet IP address
firewall1-dmz.example.com = IP address on DMZ network
firewall1-management.example.com = IP address on out-of-band management
network

You could even CNAME firewall1 to firewall1-management as this is
(presumably) the interface that users and monitoring/management tools will
want to reach by default.

The hostname of the box is "firewall1" but each interface on it has a
unique name, derived from the hostname plus a "-" suffix. Select
a set of well known and used suffixes for your environment.
If someone really wants to try and SSH to the Internet interface (though I
don't understand why you would), they know the hostname and they know the
suffix, so it's a simple matter of combining them.


On Fri, 1 Mar 2024 at 21:11, Nick Tait via bind-users <
bind-users@lists.isc.org> wrote:

> On 02/03/2024 03:42, Mike Mitchell via bind-users wrote:
>
> Our networking team is in the habit of entering the IP address of every
> network interface on a router under one name.  The very first address
> entry is their out-of-band management interface.  "rrset-order fixed" is
>  used on their domain for address records, so they can ssh to the router
>  by name reliably and not have to worry about interfaces that are down
> or that filter SSH.
>
> I wonder if an alternative (cleaner?) solution to your use case could be
> to use different sub-domains for the different networks (network
> interfaces)? For example:
>
> firewall1.example.com = Internet IP address
> firewall1.*dmz*.example.com = IP address on DMZ network
> firewall1.*management*.example.com = IP address on out-of-band management
> network
>
> If you did this you could make use of DNS search domains to allow
> different parts of the network to resolve the unqualified name "firewall1"
> differently. E.g. If you "ssh firewall1" from a management host it could
> expand that to firewall1.*management*.example.com?
>
> Nick.
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"

[Greg Choules via bind-users]

2nd $beverage consumed.
I have never liked sortlist since I inherited it 16 years ago in my
previous job.

For me it suffers from at least one fundamental problem:
- If a client, say at location "1", is given a bunch of sorted A records
with the server at location "1" first, what does the client do when the
server at location "1" is down?

Clients come in many varieties. Some are capable of cacheing multiple
answers, timing out and trying a different one, some are not. This leads to
service reliability issues because, even though a perfectly healthy
instance of the service may exist at site "2", clients (at site "1") are
still told by DNS, go to site "1"

The DNS service is not (by default) either application or client-aware. It
just gives the answers you tell it to, whether they're working or not.

If you want an efficient, reliable multi-site service, use load-balancers
that can direct traffic from local clients to a local service instance, or
use an application aware DNS server (I can think of one; I'm sure others
exist) that monitors availability, delay and whatever other metrics are
important and feeds the DNS resolvers with *the* answer they want them to
give to a client at this moment in time. ECS would even allow said box to
be aware of client location, to use as an additional metric when making
this decision.

In summary, Do the hard work of traffic steering somewhere else and let
your DNS resolvers deliver the chosen answer. Don't make the resolvers
themselves try to do this on the basis of incomplete information.


On Fri, 1 Mar 2024 at 10:12, G.W. Haywood  wrote:

> Hi there,
>
> On Fri, 1 Mar 2024, Matus UHLAR wrote:
> > On 01.03.24 08:24, Ond?ej Sur? wrote:
> > > The "sortlist" option allows to define a complicated rules when and
> > > how to reorder the resource records in the responses. The same
> > > caveats as with the "rrset-order" apply - relying on any specific
> > > order of resource records in the DNS responses is wrong.
> > >
> > > We are not aware of any other (major) DNS server that would have
> > > similar behaviour as this was never specified in the DNS protocol.
> > > If you know of any software or hardware relying on any specific
> > > order of the resource records in the DNS messages, it needs to
> > > be reported as a bug to the respective vendor.
> >
> > I don't know about _requirement_, but I have used this option as poor
> > man's way to implement geographically local IP addresses
> > - to anyone return topologically closer IP addresses first, others next.
>
> Maybe I need more of my morning $beverage but this sort of thing seems
> to me to militate against other - existing - efficiency mechanisms.
>
> Network performance isn't just about topology, there are things like
> performance and load to consider.  Might your tweaked responses just
> send clients to a nearby but tragically overloaded server?
>
> My preference would be to let those people whose job it is to think
> about this stuff - which, reading this list, clearly they do - get on
> with their job.
>
> Observations welcome of course.
>
> --
>
> 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: Deprecated DSCP support

[Greg Choules via bind-users]

Hi Wolfgang.
Firstly let me say that I have never been a fan of QoS. So I'm slightly
biased against the whole thing in the first place.

But regarding your comment "It’s not easy for the network to guess the
requirements of an application," I would disagree. Traffic classification
and setting of DSCP values is something that edge routers have been capable
of for decades. I would even argue that this is the place you *want* to do
it, rather than trusting what the application itself says it wants.

If you must do the whole QoS thing at all, use something like a policy-map
(other manufacturers are available), match all port 53, set DSCP to an
appropriate value for *your* network and prioritise/police as appropriate
in the core.

Cheers, Greg

On Thu, 29 Feb 2024 at 09:00, Wolfgang Riedel via bind-users <
bind-users@lists.isc.org> wrote:

> Hi Folks,
>
> OK let me help you a bit as it’s really essential for DNS traffic which
> need to be go through in all situations!!!
>
> Within the OS networking stack as also within the network there is always
> a prioritisation of packets within the queues to serialise the packets of
> an application to go on the wire. This prioritisation is being done based
> on DSCP within a L3 domain and on COS when in a L2 domain.
>
> It’s not easy for the network to guess the requirements of an application,
> therefore best case the application is setting the DSCP itself and the
> network is just trusting the DSCP or if smart enough the checking and in
> case of violation doing reclassification.
>
> In my case it’s dscp 24 in named.conf options but the value may be
> different based on deployment scenarios and therefore needs to be a
> configureable option.
>
> If you don't set it, it will default to 0 and all other traffic will get
> higher priority. Saying if you do an ftp download with large frames, your
> DNS request which will be running in parallel will not be making it through
> and either get delayed or typically drooped.
>
> Maybe have a look at the following classification scheme:
>
> [image: 640px-IETF_Logo.svg.png]
>
> RFC 4594-Based 12-Class QoS Model
> <https://www.f1-consult.com/qos/rfc4594/>
> f1-consult.com <https://www.f1-consult.com/qos/rfc4594/>
> <https://www.f1-consult.com/qos/rfc4594/>
>
> —
> Hope that helps,
> Wolfgang
> __
> 
> Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559
>
>
> On 28. Feb 2024, at 22:01, Petr Menšík  wrote:
>
> We may want to help fixing DSCP features, but I personally do not know any
> usage, where this feature would be used and what for exactly. Recent bind9
> uses libuv to back its network core, instead of custom networking core
> maintained by ISC. But I haven't found any trace of DSCP support at libuv
> docs [1]. I haven't found a way to set at least type of service on UDP [2].
>
> I think that would be the first place to support DSCP values for
> connections or sockets. Then, once libuv can use it, its support could be
> added back into named.
>
> It would help though if you were more verbose about why iptables cannot
> replace it and what is use-case, when it is useful. Without simple
> alternatives present. If you would describe it, it might motivate more
> people to work on DSCP support. I haven't seen important reason, why it
> needs to be done by the daemon itself. Perhaps we can find alternative way
> to set DSCP tags for you, if you are more verbose about how you use it?
>
> Regards,
> Petr
>
> 1.
> https://docs.libuv.org/en/v1.x/search.html?q=dscp&check_keywords=yes&area=default
> 2. https://docs.libuv.org/en/v1.x/udp.html
>
> On 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote:
>
> Hi,
> I am working on a product in Nokia, and we currently use BIND provided by
> Rocky Linux 8 with security patches. Recently the requirement came that we
> should upgrade to at least 9.16. During the testing of this version we
> realized that a feature we used, DSCP, has stopped working. Reading about
> the topic, we found the article about it non-operational in 9.16, and
> removal in 9.18.
>  We also saw the email on this mailing list, stating that "so far, nobody
> has noticed" it is missing. Well, we noticed it just now, and I would like
> to state that our product and most probably other telecom equipments using
> BIND would miss it greatly. As I read in that mail, there was an
> alternative plan which would re-implement this functionality. If it is
> feasible, please consider doing it. The alternative options, e.g. setting
> it via iptables cannot work in our use-case.
>  Best regards,
> Bala

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: 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"
&

Re: Question about authoritative server and AA Authoritative Answer

[Greg Choules via bind-users]

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

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

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

Re: Unhelpful startup message re: RPZ

[Greg Choules]

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

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

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

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

Hope that helps.
Cheers, Greg



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

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

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


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

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

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 1

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: 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: 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: Facing issues while resolving only one record

[Greg Choules via bind-users]

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

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

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

Hope this helps.
Greg

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

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

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

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: 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&state=all&label_name%5B%5D=Extended%20DNS%20Errors&first_page_size=20
>
> For which errors are supported.
>
> Best regards, Matthijs
>
> On 7/11/23 11:10, sami.ra...@sofrecom.com wrote:
> > Hello ?community
> >
> > I want to use "extended dns error" option on my recursive dns server.
> > What config changes are required to enable EDE?
> >
> > I am using BIND 9.16.42 as recursive server.
> >
> > Regards Sami
> >
> >
>
>
> --
>
> Subject: Digest Footer
>
> ___
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> --
>
> End of bind-users Digest, Vol 4279, Issue 3
> ***
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

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

[Greg Choules via bind-users]

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

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

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

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

Cheers, Greg

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

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

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

[Greg Choules via bind-users]

Hi Ubence.
That is starting to get complex!

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Cheers, Greg


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

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

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

[Greg Choules via bind-users]

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

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

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

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

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

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

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

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

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


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


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

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

Re: 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: 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?)
>
>
> -

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

[Greg Choules via bind-users]

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

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

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

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

Cheers, Greg

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

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

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

[Greg Choules via bind-users]

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

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

Hope that helps, Greg


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

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

Re: 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: 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: bind9 (9.18.14) build / install on macOS Ventura (13.3.1) fails to create dirs or files as expected

[Greg Choules via bind-users]

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

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

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

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

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

Hope this helps.
Greg


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

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

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


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

Re: 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: Best practice MultiView

[Greg Choules via bind-users]

Hi Jiaming.
You're welcome.

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

Cheers, Greg

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

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

Re: Best practice MultiView

[Greg Choules via bind-users]

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

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

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


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


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

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

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


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

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

Hope that helps.
Greg

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

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

Re: 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.

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

Cheers, Greg

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

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

Re: Best practice MultiView

[Greg Choules via bind-users]

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

Cheers, Greg

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

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

Re: Best practice MultiView

[Greg Choules via bind-users]

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

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

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

Cheers, Greg

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

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

Re: bind with qname min. fails to continue recursing on one specific query

[Greg Choules via bind-users]

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

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

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

Cheers, Greg

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

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

Re: RPZ answer me NXDOMAIN for some domain

[Greg Choules via bind-users]

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

Cheers, Greg

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

> Hi there,
>
>
>
> We are using RPZ zone for some times now, but recently we found a weird
> behavior from some domains. Let me explain !
>
>
>
> We have 2 NS server : Recursive one (let’s call him SrvA) and one bebind
> (let’s call him SrvB, with global forwarder : SrvA ). My RPZ zone is on
> SrvA.
>
>
>
> If we took a little diagram, we have :
>
>
>
> User = > SrvB = > SrvA = > Internet
>
>
>
> If we create an A record tatata.google.com / 2.3.4.5 (that doesn’t exist
> at google.com) on RPZ zone :
>
>
>
>- On SrvA with : dig @localhost tatata.google.com we got IP : 2.3.4.5
>=> GREAT !
>- On SrvB with : dig @localhost tatata.google.com (that point on
>SrvA), we got IP : 2.3.4.5 => WONDERFUL !
>
>
>
> BUT
>
>
>
> If we create another A record sri.biopyrenees.net / 3.4.5.6 (that doesn’t
> exist at biopyrenees.net) on RPZ zone :
>
>
>
>- On SrvA with : dig @localhost sri.biopyrenees.net, we got IP :
>3.4.5.6 => YOUPI !
>- On SrvB with : dig @localhost sri.biopyrenees.net, we got : NXDOMAIN
>=> WHA ?
>
>
>
> Why for some domain, the RPZ isn’t working ?
>
>
>
> An exemple of what I wrote on my RPZ zone :
>
>
>
> tatata.google.com   A   2.3.4.5
>
> sri.biopyrenees.net A  3.4.5.6
>
>
>
> Is it normal ? Is there a way to have the good answer on my SrvB ?
>
>
>
> With tcpdump, I see the same behavior with a record that works and with
> the record that doesn’t work…
>
>
>
> Thanks for your help.
>
>
>
> Nath.
>
>
>
>
>
>
>
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Bind 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: 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: 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: 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]

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

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

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

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

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

Re: Intermittent issues resolving "labor.upload.akamai.com"

[Greg Choules via bind-users]

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

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

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

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

I hope that helps, Greg

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

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

Re: 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: 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: 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: 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: SERVFAIL IPv6 debugging

[Greg Choules via bind-users]

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

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

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

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

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

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

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

HTH
Greg

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

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

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


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

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