Broken DNS QNAME Recovery

[Crist Clark]

First, yes, I know. Their DNS is broken. They should fix their DNS. We
shouldn't need to make QNAME-minimization work around broken DNS.

Name and shame a domain name in question,

e1083.d.akamaiedge.akamai.csd.disa.mil

The problem I see: akamai.csd.disa.mil is a delegated zone. All four name
servers for the zone are in the zone. All four of the addresses in the
parent's glue are unresponsive. It's actually the same for
d.akamaiedge.akamai.csd.disa.mil too.

That is breaking resolution for BIND 9.18 servers with default
qname-minimization. If qname-minimization is set "off", it works. That's
because the disa.mil NSes will respond with the answer for that full name.
We never go farther up the name to try to find the non-responsive NS
servers.

(And yes, the DNS "authoritative" servers here are questionable too. The
TTLs look like they are caching answers, but all of the responses have AA
set.)

Does that assessment look correct? I know BIND defaults to "relaxed" QNAME
minimization. It works around certain cases of brokeness. I guess this is
not one of them? Should it be? It's a case where things work without
minimization. The brokeness is hidden for non-minimizing resolvers.

Again, yeah, they are broken. They should fix it, but it broke someone's
Very Important Work at our shop. And it used to work and it works from home
and for other customers so it must be our DNS that's broken. So we end up
setting "qname-minimization off" globally despite the fact they are really
the broken ones. We'd rather keep minimization on, but it's the only
reasonable work around we could find.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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

[Crist Clark]

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

Some Authoritative-Only BCPs

[Crist Clark]

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

Re: Remove PDF-related bits from the build system

[Crist Clark]

https://bind.readthedocs.io/_/downloads/en/v9.18.21/pdf/


On Thu, Dec 21, 2023 at 9:59 AM Fred Morris  wrote:

> (Intentionally posting to the mailing list with that string since that
> was the commit message where it occurred. Hopefully this will improve
> findability.)
>
> So, yeah.
>
> I'll take your word for it that Read The Docs can generate PDFs. I'd
> appreciate your promise that it generated the version of the doc which
> is here: https://downloads.isc.org/isc/bind9/9.18.21/doc/arm/Bv9ARM.pdf
> We could talk about the difference in presentation between the HTML and
> PDF versions, but it's a matter of taste.
>
> Is this free, and where are the instructions?
>
> According to the commit
> (
> https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4
> )
> you removed "PDF-related bits" from not just the build system, but from
> the documentation itself! You removed the instructions that are in the
> commit message itself! If your intention was to remove it from the build
> system, you went too far.
>
> I looked for this just the other day in the KB. At the least you should
> have a KB article. At least there's this post to the mailing list.
>
> --
>
> 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: Value of a DNSSEC validating resolver

[Crist Clark]

Preface: Please don’t read any judgement of DNSSEC’s value into this
question. Just looking for the opportunity to understand DNSSEC better from
some world-class experts if any care to respond.

When a client (or any DNS-speaker) is doing validation, doesn’t it set CD
on queries through a forwarder? In that sense, the intermediate servers do
not filter “bad answers.” Or is my understanding incorrect? Or do you mean
the data that the forwarder is using internally has been filtered of bad
answers?


On Fri, Dec 1, 2023 at 1:40 PM Mark Andrews  wrote:

> A validating resolver is a prerequisite for validating clients to work.
> Clients don’t have direct access to the authoritative servers so the can’t
> retrieve good answers if the recursive servers don’t filter out the bad
> answers.
>
> Think of a recursive server as a town water treatment plant. You could
> filter and treat at every house and sometimes you still do like boiling
> water for baby formula but on the most part what you get out of it is good
> enough for consumption as is.
>
>
> --
> Mark Andrews
>
> On 2 Dec 2023, at 08:14, John Thurston  wrote:
>
> 
>
> At first glance, the concept of a validating resolver seemed like a good
> idea. But in practice, it is turning out to be a hassle.
>
> I'm starting to think, "If my clients want their answers validated, they
> should do it." If they *really* care about the quality of the answers they
> get, why should my clients be trusting *me* to validate them?
>
> Can someone make a good case to me for continuing to perform DNSSEC
> validation on my central resolvers?
>
> --
> --
> 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
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: sub-subdomian not being resolved NXDOMAIN.

[Crist Clark]

Ancient BIND version, but won’t mention it beyond that. Others are going to.

This should work fine. Having multiple levels of labels in the zone
shouldn’t be a problem. But you’re not providing enough detail to
troubleshoot. You’re going to have to show the config and zone files to
really get any help. And just just providing snippets of the files might
not show where the problem is. You also should provide the “dig” output and
the precise errors you get back (e.g. the SOA record returned in the
NXDOMAIN response might provide clues).


On Sat, Dec 2, 2023 at 4:47 PM Michał Półrolniczak <
michal.polrolnic...@gmail.com> wrote:

> Hello Bind Community,
>
> Im trying to resolve sub-subdomain without making each level as separate
> zone file.
>
> I have domain.my (name of domain changed) in main zone (the host I serve
> it from is ns.domain.my) - this works fine, I delegated sub domain
> my.domain.my by adding:
>
> my.domain.my IN NS ns.domain.my; I added this zone to config file and
> created zone file for it. - this also works fine
>
> I can without any issues add subdomain to my.domain.my in my.domain.my
> zone file.
>
> I would like to resolve sub-subdomain like: this.is.also.my.domain.my
> from same my.domain.my zone file.
> from my understanding I could add wildcard: "*.is.also.my.domain.my. IN A
> ip.addr" record (and handle it later on server), or by adding "
> this.is.also.my.domain.my. IN A ip.add" record.
> Both don't work sadly.
>
> I also tested "is.also.my.domain.my. A ip.address" which also dont work -
> so it looks like im missing something.
>
> Was this feature disable/removed from bind9 or I forgot to set something
> in my config file?
>
> I'm using bind9 9.11.5
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: What is the equivalent of this dnsmasq configuration

[Crist Clark]

Pretty much a precise use case for RPZ (Response Policy Zones). Google it
or search the BIND docs for RPZ.

On Sun, Jun 18, 2023 at 8:37 PM public1020 via bind-users <
bind-users@lists.isc.org> wrote:

> I need to hijack certain domains and not its subdomains, so I use dnsmasq
> to achieve it:
>
> ```
> host-record=example.com ,1.2.3.4
> ```
>
> In bind I have to create a zone and copy everything there, is there a
> simple way for domains I have no authority for?
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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

[Crist Clark]

That should return a NXDOMAIN. Returning SERVFAIL is never a normal RPZ
action. Something is wrong with your configuration.

On Fri, Jun 16, 2023 at 1:39 PM  wrote:

>
>
> Hello
>
> For monitoring reasons I try to change the return code of a domain name
> from "SERVFAIL" to "NXDOMAIN" with the rpz classic configuration of
> BIND9.16.42 as follows:
>
> example.com IN CNAME.
>
> *.example.com IN CNAME .
>
> But it still doesn't work, I still have the message  " SERVFAIL", is it
> feasible or not please ?
>
> Kind regards
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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 error resolving gpo.gov ?

[Crist Clark]

rndc dumpdb
rndc flushtree gov

Did that help? Going back to the dumped cache, what do the relevant names
have in there?


On Tue, Mar 14, 2023 at 5:46 PM Alexandra Yang  wrote:

> Hi Mark,
>
> We noticed the problem because client can't resolve
> www.federalregister.gov, hosted by ns3.gpo.gov and ns4.gpo.gov. Our error
> is similar to the previous post, plus some errors with the gpo.gov
> nameserver.I just wonder if it's the config problem with our BIND 9.16.37
> or problem with the gpo.gov nameserver ?
>
> We have dnssec-validation yes, not sure what to do if there is problem
> with our config.
>
>
> Mar 13 18:02:18 ipam-dns-bl-5 named[2881]: client @0xaf1cb158
> 10.10.99.155#55940 (ns3.gpo.gov): query failed (broken trust chain) for
> ns3.gpo.gov/IN/A at
> /mnt/proj/package-7-3/nessy/bind-9.16/lib/ns/query.c:7449
>
>
> Mar 14 10:23:32 ipam-dns-in-1 named[3713]: broken trust chain resolving 
> 'ns3.gpo.gov/A/IN': 162.140.15.100#53
>
>
> Mar 13 16:18:46 ipam-dns-bl-4 named[2928]: broken trust chain resolving '
> www.federalregister.gov//IN': 162.140.15.100#53
>
>
>
> Thanks!
>
>
>
> On Tue, Mar 14, 2023 at 7:30 PM Mark Andrews  wrote:
>
>> Why are you trying to query this address?  The IPv4 servers are
>> 162.140.15.100
>> and 162.140.254.200.
>>
>> > On 15 Mar 2023, at 07:53, Darren Ankney 
>> wrote:
>> >
>> > This is failing for me regularly:
>> >
>> > $ dig ns3.gpo.gov +dnssec +norecurse @162.140.15.200
>> > ;; communications error to 162.140.15.200#53: timed out
>> > ;; communications error to 162.140.15.200#53: timed out
>> > ;; communications error to 162.140.15.200#53: timed out
>> >
>> > ; <<>> DiG 9.18.11 <<>> ns3.gpo.gov +dnssec +norecurse @162.140.15.200
>> > ;; global options: +cmd
>> > ;; no servers could be reached
>> >
>> > but all other combos of ns3.gpo.gov or ns4.gpo.gov and 162.140.15.100
>> > and 162.140.15.200 work fine.
>> >
>> > On Tue, Mar 14, 2023 at 12:03 PM Tim Maestas 
>> wrote:
>> >>
>> >> I've been having problems resolving www.federalregister.gov which is
>> served by ns3.gpo.gov and ns4.gpo.gov, using BIND 9.16.27.  Haven't been
>> able to quite figure out why so I've stuck an NTA in for the time being.
>> >>
>> >> On Tue, Mar 14, 2023 at 8:52 AM Stephane Bortzmeyer 
>> wrote:
>> >>>
>> >>> On Tue, Mar 14, 2023 at 11:35:38AM -0400,
>> >>> Alexandra Yang  wrote
>> >>> a message of 183 lines which said:
>> >>>
>>  I wonder if any of your nameserver resolve it just fine, like 8.8.8.8
>>  works
>> >>>
>> >>> Among RIPE Atlas probes, most succeed:
>> >>>
>> >>> % blaeu-resolve --displayvalidation -r 100  --type A gpo.gov
>> >>> [ (Authentic Data flag)  162.140.14.82] : 46 occurrences
>> >>> [162.140.14.82] : 52 occurrences
>> >>> [ERROR: SERVFAIL] : 2 occurrences
>> >>> Test #50935448 done at 2023-03-14T15:46:50Z
>> >>>
>> >>> The two whose resolvers servfail may have stricter/paranoid resolvers.
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW
>> 
>> 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.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
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Changing DNS servers (name only) for a DNSSEC enabled domain

[Crist Clark]

What new DS record? The KSKs aren’t changing, are they? Why would they?

All that is changing is the NS RRset (and maybe SOA if you’re changing the
MNAME).

If the NS glue in the parent doesn’t agree with the canonical NS RRset in
the child, this is not a DNSSEC fail. This is as easy as changing any other
records in the zone.

I think all of these complications arise if you are not only changing NS
servers, but also changing registrars. I think that may be the implicit
assumption. That was not mentioned as part of this change.


On Mon, Feb 13, 2023 at 9:03 AM Mark Elkins via bind-users <
bind-users@lists.isc.org> wrote:

> If the IP addresses of the DNS servers (dns[123].olddomain and
> dns[123].newdomain) are staying the same - then you only need to send an
> update to change your domain from being hosted at olddomain to newdomain.
> Ideally, the newdomain would be created first (pointing to the same IP
> addresses as in olddomain) in the Registry, then after a day or two, have
> the olddomain in the Registry deleted - but it shouldn't really matter.
>
> People who are looking for DNSSEC records will still go to the correct
> places - because the IP addresses at those places are not changing.
> On 2023/02/13 17:58, Danilo Godec via bind-users wrote:
>
> Hello,
>
>
> in the near future I will have to change NS records for one of my domains,
> as DNS servers currently use an old domain (not mine), that will be phased
> out. DNS servers will actually remain the same, only the domain name will
> change.
>
> So, basically:
>
>
>- mydomain currently uses dns1.olddomain, dns2.olddomain,
>dns3.olddomain, ...
>- dns*.olddomain are the same servers as dns*.newdomain
>- mydomain has to change DNS server to dns1.newdomain, dns2.newdomain,
>dns3.newdomain, ...
>
>
>
> Since DNSSEC is enabled on mydomain, I've been reading some instructions
> about doing this with DNSSEC and they say:
>
> 1. Disable DNSSEC at Registrar
> 2. Wait 24 hours
> 3. Disable DNSSEC at Name Server (remove DS-records)
> 4. Switch name servers
> 5. Wait 24 hours
> 6. Re-enable DNSSEC
>
> I personally prefer,
>
> Create the Domain on the new nameservers, sign it, send the new DS record
> to the Registry. This probably means loading the DS record via the old
> (existing) Registrar. Wait 24 hours (propagation time) then update (swap)
> the Nameservers at the Registry to the new Nameservers.
> Wait a day or two then remove the domain from the old servers.
> As long as one of the DS records matches the DNSKEY on either the old or
> new Nameservers - DNSSEC should validate.
>
> The problem is - not many Registrars allow a foreign DS record to be
> loaded in their system for uploading to the Registry. I do allow the client
> to do this. Don't think it has ever happened though.
>
>
>
>
> Is this really necessary in this case, changing only DNS server names? I
> would like to avoid changing DS records at the registrar level as they
> don't provide a 'self-service' interface for managing them, so I have to go
> though their support and that's usually tedious.
>
> If that is necessary, why?
>
>
>Thanks, Danilo
>
> PS: If it matters, this is (still) a manually DNSSEC'd domain.
>
> --
>
> Mark James ELKINS  -  Posix Systems - (South) Africa
> m...@posix.co.za   Tel: +27.826010496 <+27826010496>
> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>
> [image: Posix Systems][image: VCARD for MJ Elkins]
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: [KASP] setup KASP in master / slave architecture

[Crist Clark]

The statement that a BIND secondary only uses one file is incorrect. A
secondary will write IXFR data to a journal file, a jnl file.

But as has been stated earlier in the thread, a secondary is not involved
in anyway in signing a zone. One way to possibly make more sense of this is
to consider how DNSSEC is designed so caching server also can provide all
of the records needed to validate. It definitely has no special knowledge
of the keys, singing policies, no zone files, etc.


On Fri, Dec 16, 2022 at 12:51 PM Darren Ankney 
wrote:

> This is all I have in my zone on secondary:
>
> zone "mylocal" {
>
>   type secondary;
>
>   file "/etc/bind/mylocal.saved";
>
>   primaries {
>
> 192.168.40.142;
>
>   };
>
> };
>
> My primary is a little more complicated:
>
> zone "mylocal" {
>
>   type primary;
>
>   file "/etc/bind/mylocal";
>
>   notify yes;
>
>   allow-update {
>
> key kea_bind_DDNS_SEC;
>
>   };
>
>   allow-transfer {
>
> key "192.168.40.142-192.168.40.182-zone-transfer";
>
>   };
>
>   dnssec-policy default;
>
> };
>
> I just removed the zone and .jnl files from secondary and restarted. The
> actual zone: mylocal.saved showed up immediately.  About an hour
> later mylocal.saved.jnl appeared.
>
> On Dec 16, 2022, at 10:59 AM, adrien sipasseuth <
> sipasseuth.adr...@gmail.com> wrote:
>
> Hi,
>
> I deleted my zone file .db on my slaves and I forced a transfer from
> the master.
>
> Now it seems to work, I do have the RRSIG associated with my RRset A when
> I do a dig from my slave.
>
> When I test my dig from my internal network I actually don't have the ad
> flag. But from the google resolver (https://dns.google/) I have the flag.
>
> To summarize:
> - on my master : declaration of my policy and I use it in my zone
> configuration
> - on the slaves : configuration of my zone, standard without mentioning
> dnssec-policy
>
> What I observe:
> - on the master: files .db, .db.jbk,
> .db.signed,.db.signed.jnl and my keys
> - on the slaves: files .db
>
> I don't understand why there is no .db.signed file on my slave
> knowing that a dig from a slave does return RRSIG.
>
> zone  "**" {
> type slave;
> masters {  ** ; };
> file "/ **/ ** / ** .db";
> };
>
> Should I specify the .db or the .db.signed ? On the master
> or/and ths slaves ?
>
> Regards,
>
> Adrien
>
> Le jeu. 15 déc. 2022 à 19:10, Darren Ankney  a
> écrit :
>
>> I have a simple “mylocal” zone setup with a primary and secondary server.
>>
>> my primary has this .jnl file:
>>
>> mylocal.jnl
>>
>> My secondary has this similar .jnl file:
>>
>> mylocal.saved.jnl
>>
>> which I believe was distributed via zone transfer.  You find no such
>> similar files on your secondary?
>>
>> If you
>>
>> dig @ .. A +dnssec +multiline
>>
>> where  is the IP of your recursive server and
>> .. is something in the domain you are trying to
>> verify the DNSSEC is working.
>>
>> Does your flags line look something like this?
>>
>> ;; flags: qr rd ra ad;
>>
>> Per the manual:
>>
>> The important detail in this output is the presence of the ad flag in the
>> header. This signifies that BIND has retrieved all related DNSSEC
>> information related to the target of the query (ftp.isc.org) and that
>> the answer received has passed the validation process described in How Are
>> Answers Verified?. We can have confidence in the authenticity and integrity
>> of the answer, that ftp.isc.org really points to the IP address
>> 149.20.1.49, and that it was not a spoofed answer from a clever attacker.
>>
>>
>>
>> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#using-dig-to-verify
>>
>> My “flags” line does not show the “ad” flag as this is just a set of
>> private servers on a local lan. I can’t submit the DNSSEC details upstream
>> as described here:
>>
>>
>> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#uploading-information-to-the-parent-zone
>>
>>
>> On Dec 15, 2022, at 12:05 PM, adrien sipasseuth <
>> sipasseuth.adr...@gmail.com> wrote:
>>
>> Hi,
>>
>> Ok, I got confused, no need for the keys on the slavs actually.
>>
>> On the other hand, my slaves should generate the .signed, .signed.jnl and
>> .jbk files of my zones, no? currently it is not my case, should I copy them
>> from the master?
>>
>> moreover, when I test a "dig A" I don't have the associated RRSIG when I
>> do my "dig A" on a slave while on the master I do.
>>
>> Regards,
>> Adrien
>>
>>
>> --
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>> from this list
>>
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://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
> 

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Crist Clark]

On Sat, Oct 22, 2022 at 3:20 PM Sandro  wrote:
[snip]


> Doing favors for the better good does not seem to be in their
> dictionary. Look at DNSSEC.
>

Do you mean signing their domains or their public resolver services?

https://developers.google.com/speed/public-dns/faq
Does Google Public DNS support the DNSSEC protocol?

Google Public DNS is a validating, security-aware resolver. All responses
from DNSSEC signed zones are validated unless clients explicitly set the CD
flag in DNS requests to disable the validation.

https://developers.cloudflare.com/1.1.1.1/faq/#how-does--work-with-dnssec
How does 1.1.1.1 work with DNSSEC?

1.1.1.1 is a DNSSEC validating resolver. 1.1.1.1 sends the DO (DNSSEC OK)
bit on every query to convey to the authoritative server that it wishes to
receive signed answers if available. 1.1.1.1 supports the signature
algorithms specified in Supported DNSKEY signature algorithms
.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Dig -x +trace?

[Crist Clark]

Also should point out that when you do a +trace, your /etc/resolv.conf is
irrelevant since dig is going to try to figure things out from the root on
its own.

The fact you were careful to talk about your resolv.conf signals that you
may not be troubleshooting whatever you think you are.

What is the real problem here?

On Thu, Sep 29, 2022 at 3:57 PM Mark Andrews  wrote:

>
>
> > On 30 Sep 2022, at 07:50, Mike Hodson  wrote:
> >
> > I'm attempting to figure out how/why my reverse DNS delegation is broken.
> > I've already deleted systemd-resolved's temporary resolv.conf and added
> in an immutable single line
> > nameserver 1.1.1.1
> > resolv.conf.
> >
> > I can dig +trace forward hostnames fine.
> > I cannot dig -x an ip +trace.
> > All I get is the root-servers instead of any sort of reverse looking up
> happening at all.
> > What am I doing wrong?
>
> Hiding the actual address you are wanting the reverse lookups for.  Really
> you have an incredible resource here of knowledgeable people with millennia
> of experience between them who would have looked at every delegation and
> then would have told you what they saw that was wrong.
>
> Not installing maintenance releases when they are released.  dig +trace is
> a little fragile in 9.18.1 following the change to libuv.  Upgrade to a
> current release.
>
> > Thanks,
> >
> > Mike
> >
> > $ dig -x 208.x.x.x +trace
> >
> > ; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> -x 208.x.x.x +trace
> > ;; global options: +cmd
> > .   509855  IN  NS  a.root-servers.net.
> > .   509855  IN  NS  b.root-servers.net.
> > .   509855  IN  NS  c.root-servers.net.
> > .   509855  IN  NS  d.root-servers.net.
> > .   509855  IN  NS  e.root-servers.net.
> > .   509855  IN  NS  f.root-servers.net.
> > .   509855  IN  NS  g.root-servers.net.
> > .   509855  IN  NS  h.root-servers.net.
> > .   509855  IN  NS  i.root-servers.net.
> > .   509855  IN  NS  j.root-servers.net.
> > .   509855  IN  NS  k.root-servers.net.
> > .   509855  IN  NS  l.root-servers.net.
> > .   509855  IN  NS  m.root-servers.net.
> > .   509855  IN  RRSIG   NS 8 0 518400
> 2022101217 2022092916 20826 .
> FkcsBmNz2oK02ARhYfNSfxbnEL93RITDteQtHQoPn8zHZg9B6BRXqkH9
> +UpAEViDraX+4l8YJiUvYzrHh9twpQry0vv7xgDLoDdU9kRqokG5DEoq
> Ueqph6qleC6Vylga4f1MzW
> > N+Dh9zK9/eCSp6WxwgbnW53a9GMDbI5KWZ
> WkcWw3IPHVvVwDZfWhrKJtKZ3hafsGgmigm9F01Xk17prOAS6jBbvYjT
> jCUyTl3UZJ+bAKS4tkpFdjp78raxBKBQPN6TzdLjtxYQrhriZZ3Gjdcg
> dT+WQkLGYuyeakm2JqVe9vXGMGn0XkZEGMYnh7iW80N1XHyBMfhzGO+s 61zvWA==
> > ;; Received 1097 bytes from 1.1.1.1#53(1.1.1.1) in 12 ms
> >
> >
> > --
> > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
> >
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.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: Installing bind on Windows 10

[Crist Clark]

Windows Subsystem for Linux (WSL) is easy enough to install. BIND, tools
included, will run just fine in there.

On Fri, Sep 9, 2022 at 7:35 AM Brown, William  wrote:

> After I hit send, I thought I should add this request to ISC:
>
>
>
> Can you keep supporting dig (and perhaps other select tools) on Windows?
> Some of us are forced to use Windows workstations while the servers run
> some *nix flavor.
>
>
>
>
>
> --
>
> William Brown
>
> WNYRIC/Erie 1 BOCES
>
> 716-821-7285
>
>
>
> Email and Spam Filtering Please reach out to exchgt...@e1b.org
>
> For Immediate Needs Call our Service Desk at 716-821-7171
>
>
>
> *From:* bind-users  * On Behalf Of *Brown,
> William
> *Sent:* Friday, September 9, 2022 10:29 AM
> *To:* Ahmad Ibrahim ; bind-users@lists.isc.org
> *Subject:* RE: Installing bind on Windows 10
>
>
>
> * This email originated from outside of the organization. Use
> caution when replying, opening attachment(s), and/or clicking on URL's.
>  *
>
>
>
> The service account is to run BIND as a DNS server.  Click the box to
> install tools only.  Add the directory containing the extracted files to
> you path in Windows to make life easier.
>
>
>
>
>
> --
>
> William Brown
>
> WNYRIC/Erie 1 BOCES
>
> 716-821-7285
>
>
>
> Email and Spam Filtering Please reach out to exchgt...@e1b.org
>
> For Immediate Needs Call our Service Desk at 716-821-7171
>
>
>
> *From:* bind-users  *On Behalf Of *Ahmad
> Ibrahim
> *Sent:* Thursday, September 8, 2022 11:32 PM
> *To:* bind-users@lists.isc.org
> *Subject:* Installing bind on Windows 10
>
>
>
> * This email originated from outside of the organization. Use
> caution when replying, opening attachment(s), and/or clicking on URL's.
>  *
>
>
>
> *Hello I'm working installing an equivalent to dig on windows and stumbled
> upon the following site: https://phoenixnap.com/kb/dig-windows
> *
>
>
>
> *During the installation I'm asked for a service account - I don't believe
> I have any additional accounts on the computer - will I be required to
> create another one as a service account? Additionally I am unable to
> install due to the Visual C++ 2017 requirement. I have a number of
> different Visual Studio Redistributables installed (I am unable to upload
> an image as part of this support request). I do not feel comfortable
> uninstalling them randomly but I do have one (2015-2022 x64 14.32.31332)
> that seems to be more current than the one bundled with the installation.*
>
>
>
> Confidentiality Notice: This electronic message and any attachments may
> contain confidential or privileged information, and is intended only for
> the individual or entity identified above as the addressee. If you are not
> the addressee (or the employee or agent responsible to deliver it to the
> addressee), or if this message has been addressed to you in error, you are
> hereby notified that you may not copy, forward, disclose or use any part of
> this message or any attachments. Please notify the sender immediately by
> return e-mail or telephone and delete this message from your system.
> Confidentiality Notice: This electronic message and any attachments may
> contain confidential or privileged information, and is intended only for
> the individual or entity identified above as the addressee. If you are not
> the addressee (or the employee or agent responsible to deliver it to the
> addressee), or if this message has been addressed to you in error, you are
> hereby notified that you may not copy, forward, disclose or use any part of
> this message or any attachments. Please notify the sender immediately by
> return e-mail or telephone and delete this message from your system.
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Can't modify an existing SPF record

[Crist Clark]

As far as BIND is concerned, this is arbitrary text in a TXT record. It
doesn’t know or care about SPF syntax within it.

It sounds like you’re having webmin problems, not BIND.

On Fri, Jul 8, 2022 at 9:08 AM Ondřej Surý  wrote:

>
> > On 8. 7. 2022, at 18:05, Roberto Carna  wrote:
> >
> > using the CLI in the BIND master
>
> What does this mean and how exactly are you changing the zone? List all
> the steps that you are doing when changing the zone contents.
>
> Ondrej
> --
> Ondřej Surý — ISC (He/Him)
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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 www.ecb.europa.eu tages ages

[Crist Clark]

DNSViz is usually the go-to tool when trouble shooting
is-it-me-or-is-it-them DNSSEC issues, but it’s thorough enough to help for
a lot more general problems too.

Someone else has been using it to check that name,

https://dnsviz.net/d/www.ecb.europa.eu/dnssec/

The only thing that pops up that might hint at your problem are a couple of
unresponsive servers in the mix. Questionable that it’s really a cause to
your problem.

A note about the “dig +trace” below. They’re pretty and all, but really
aren’t a good representation of what your resolver really does. In your
case for example, it quits when it gets the CNAME. It doesn’t follow
through to get the A record it points to. Problems with QNAME minimization,
“bad” data in the cache, and other things won’t show up in a +trace.


On Fri, Jun 17, 2022 at 4:05 AM Matus UHLAR - fantomas 
wrote:

> Hello,
>
> I encountered case where resolution of www.ecb.europa.eu takes long time
> and
> I can't find out why.
>
> I'm trying to find the culprit using dig +trace and resolution times
> change
> from < 1 second to > 15 seconds, while response times reported by dig say
> miliseconds.
>
> multiple runs of dig seem to fix the issue until I clear named cache.
> (which indicated problem is in DNS, but I still have no idea where)
>
> I'm out od ideas what to search for.
>
> I have debian 11 with bind version 1:9.16.27-1~deb11u1
>
> an example dig that took 5 seconds pasted:
>
> # time dig +trace www.ecb.europa.eu
>
> ; <<>> DiG 9.16.27-Debian <<>> +trace www.ecb.europa.eu
> ;; global options: +cmd
> .   194472  IN  NS  m.root-servers.net.
> .   194472  IN  NS  k.root-servers.net.
> .   194472  IN  NS  f.root-servers.net.
> .   194472  IN  NS  g.root-servers.net.
> .   194472  IN  NS  h.root-servers.net.
> .   194472  IN  NS  d.root-servers.net.
> .   194472  IN  NS  b.root-servers.net.
> .   194472  IN  NS  c.root-servers.net.
> .   194472  IN  NS  l.root-servers.net.
> .   194472  IN  NS  e.root-servers.net.
> .   194472  IN  NS  j.root-servers.net.
> .   194472  IN  NS  a.root-servers.net.
> .   194472  IN  NS  i.root-servers.net.
> .   194472  IN  RRSIG   NS 8 0 518400
> 2022062605 2022061304 47671 .
> iUnxO5EIpOY35jg5SR2+ZW9mYcieUMFZn2JwNHpEPW/YxGfXh+XjLXpC
> n+ByMYEB2L1b1zzcx86wnyKxnuhU8O/EH63w13op+lo+MxVOJlFOribp
> 6jV2BZn+fHCJDE/5VHtSGYI741Uf1aUudjrX7htYVngg7Z1eTI0PinGN
> Z46j/xRcwk5KlHKExmgQSlS1FrLT0yiBeT6Tg48guYfYKbpDNIcy3vS4
> 7BIv7U0jDmynl8cOYlfgDH2Nft6Vw3vrrVjMFkyWsIdFCsfejrff8UqR
> JhuE47lm0JdhV7z+3NfoJRANaRjAfD0ufB1chXuFQpsuquAZ907fh+e3 +Ny+kg==
> ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>
> eu. 172800  IN  NS  x.dns.eu.
> eu. 172800  IN  NS  si.dns.eu.
> eu. 172800  IN  NS  be.dns.eu.
> eu. 172800  IN  NS  w.dns.eu.
> eu. 172800  IN  NS  y.dns.eu.
> eu. 86400   IN  DS  59479 8 2
> 5DBAA81BC0BEFE921886D8DA28498D9FD441B457FB0E3642A0B2F981 1C8E15E0
> eu. 86400   IN  RRSIG   DS 8 1 86400
> 2022063005 2022061704 47671 .
> ng+6lWObqlR9d72YQ+i4K5NGoIqgUfgADqrrrw83a7nVIZzM0vLNwsA2
> h7lOAClHLNzYtaSh3Y9RmjjfaOEggPX/qHe1CXr9OG+Ezn1TiQHIBZ8b
> EDO2sub4oUG6SqBCM4TEcFodiDV1XaNhOFxbQ++7woya3JlDGfG77Dpi
> osL8LqZNwvrMcMglfC/anDJwPkE4n4Ywd/UMpsG6+An/HSMn/DLRmaBy
> Xt1IhMzRZKeIshqVLS0i/JT8A2jzFQjhn80CGAoGe7Lfhk393E81Bm2h
> lJGsBFaPdoX8oLjvPsjk7kgu4RCNM82zR0GAA0CxJurph7u/PQDlNwFY EqvVOQ==
> ;; Received 719 bytes from 192.112.36.4#53(g.root-servers.net) in 19 ms
>
> europa.eu.  86400   IN  NS  ns1.bt.net.
> europa.eu.  86400   IN  NS  ns2eu.bt.net.
> europa.eu.  86400   IN  NS  ns1bru.europa.eu.
> europa.eu.  86400   IN  NS  ns1lux.europa.eu.
> europa.eu.  86400   IN  NS  ns2bru.europa.eu.
> europa.eu.  86400   IN  NS  ns2lux.europa.eu.
> europa.eu.  86400   IN  NS  ns3bru.europa.eu.
> europa.eu.  86400   IN  NS  ns3lux.europa.eu.
> europa.eu.  86400   IN  NS  ns4az1.europa.eu.
> europa.eu.  86400   IN  DS  6250 8 2
> 0186EEFF28A83D2C950963CEEF2F2070DC0885AC8AD7106B03A9741C 25DC6B82
> europa.eu.  86400   IN  DS  14845 8 2
> 9EF3C28F5B3A3D33756D61715B1BDBDBB07E098D30256D1F2B71 95324846
> europa.eu.  86400   IN  RRSIG   DS 8 2 86400
> 20220623041700 20220616041129 27435 eu.
> XakdaRA9D2dJc7PciufTV202vD0+QVIjdHl0G9IVkvF/UNEOZCheEJs8
> 

Re: BIND9 TSIG from Windows Server 2016 DNS Server Zone

[Crist Clark]

As far as I know, GSS-TSIG is only used for DNS updates, not zone transfers.

https://bind9.readthedocs.io/en/v9_16_5/advanced.html#dynamic-update

Sorry, don't know what capabilities AD has for securing zone transfers
beyond IP ACLs, which of course is not much security at all. I've never had
luck getting AD admins to offer anything better. I'm definitely no AD
expert myself.

One possibility of course is to secure at the IP layer, a.k.a. IPsec. You
could secure all traffic between the servers with transport mode AH. That
would probably blow some minds in your organization. There are many who
only know IPsec as encrypted tunnels, i.e. VPNs.

On Wed, May 25, 2022 at 3:38 PM Mirsad Goran Todorovac <
mirsad.todoro...@alu.unizg.hr> wrote:

> Dear all,
>
> I have a zone local.grf.hr administered by AD, DHCP and DDNS ran by
> Windows Server 2016
> (not by my architectural choice). However, since Windows Server 2016 had
> round-robin
> strategy of inquiring the forwarders, it performed worse than BIND9 on
> old Debian server.
>
> So, I had the BIND9 as the secondary server ("slave" is somewhat
> politically incorrect) and I
> wanted to secure transactions with TSIG HMAC-SHA256 or stronger, as
> between Debian
> BIND9 servers.
>
> I've been Googling around, and they say it cannot be done, because
> Windows Server uses
> special proprietary GSS-TSIG. The article was for an earlier version of WS.
>
> Has there been some improvement in the meantime?
>
> We are thinking about moving DHCP server to Linux, but it is a huge job
> to convert the
> reservations, so it may not be done in the next couple of months.
>
> I would like to secure DNS xfers from zone poisoning in the meantime,
> considering the recent
> surge of cyber attacks since the recent war started, and our country
> voted support for the
> defending party.
>
> Frankly, I am not in deep with Microsoft DNS, and I guess there can be
> some tweaking with
> the PowerShell, and maybe even some undocumented features, but right now
> I am presented
> with a problem I can't seem to solve because it is not an open system.
>
> Thanks for any help.
>
> Kind regards,
> Mirsad Todorovac
>
> --
> Mirsad Goran Todorovac
> CARNet sistem inženjer
> Grafički fakultet | Akademija likovnih umjetnosti
> Sveučilište u Zagrebu
>
> --
> CARNet system engineer
> Faculty of Graphic Arts | Academy of Fine Arts
> University of Zagreb, Republic of Croatia
> tel. +385 (0)1 3711 451
> mob. +385 91 57 88 355
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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

dnstap to Splunk

[Crist Clark]

Anyone out there trying to dump dnstap data into Splunk in
real-time or near-real-time?

I was frankly kind of surprised when I searched the Splunk docs
site and got "No results. We did not find any pages on Splunk.com
that matched dnstap."

Googling didn't fare a whole lot better. But this must be something
people out there do?

Today, we're dumping query logs from BIND into Splunk, but with
some servers trying to send logs for a few thousand queries
per second, we've had some problems. Looking ahead, we're planning
to do some server consolidation which will only up the qps on each
server even more. Dnstap seems like a possible solution.

I was hoping a Splunk module or add-on existed to eat dnstap
data directly, but that first search put a damper on that. Guess
we need to deploy middleware?
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Communication error when we do axfr query for the large size zone

[Crist Clark]

Probably.

Maybe check for any log messages from BIND. Do packet capture to see
exactly what's happening to the TCP.

On Tue, Apr 19, 2022 at 10:12 PM rams  wrote:

> Hi,
> We are getting the following error when we query for the 25M zone with
> axfr .
>
> ]# dig @localhost 25million.com axfr |tail
> a8157794.25million.com. 86400   IN  A   1.1.1.1
> a8157795.25million.com. 86400   IN  A   1.1.1.1
> a8157796.25million.com. 86400   IN  A   1.1.1.1
> a8157797.25million.com. 86400   IN  A   1.1.1.1
> a8157798.25million.com. 86400   IN  A   1.1.1.1
> a8157799.25million.com. 86400   IN  A   1.1.1.1
> a81578.25million.com.   86400   IN  A   1.1.1.1
> a815780.25million.com.  86400   IN  A   1.1.1.1
> *;; communications error to 127.0.0.1#53: end of file*
>
> Do we need to increase or set any parameters?.
>
> Regards,
> Ramesh
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Forwarding zone, setup

[Crist Clark]

You didn’t share much of your configuration except the one forwarded zone,
not a lot to go on.

But one thing to check, you do have recursion enabled on the server?

On Mon, Feb 28, 2022 at 6:34 PM Gregory Sloop  wrote:

> Wow. I hate to be the guy who looks the gift horse in the mouth - but that
> just seems "wrong." :)
>
> (Not the answer, but that that would be the way BIND wants it done.)
>
>
>
> So, now I've got two sets of NS and glue records?
>
> Please tell me that's not the way BIND insists you do this!
>
>
>
> I guess I should try it, but dang.
>
> Does anyone know for sure?
>
>
>
>
>
>
> Add Delegating NS records:
>
> ab.somedomain.local 3600 NS server1.ab.somedomain.local
> .
> .
> .
>
>
> And glue records
>
> server1.ab.somedomain.local 3600 A 10.0.0.1
> .
> .
>
>
> And see if it works. It’s got something to do with the way the record is
> matched (or not) before the forward statement is hit.
>
> J
>
> On Feb 28, 2022, at 3:47 PM, Gregory Sloop  wrote:
>
> So, I want to forward all queries for
> *.ab.somedomain.local to some other internal DNS servers.
> (Records in *.ab.somedomain.local actually are our active domain servers)
>
>
> (Yes, I know .local is reserved now, but we've been using it a long time
> and changing would be rather painful. Unless there's some horrible
> consequences, I think we'll just continue for now. We won't ever use mDNS.)
>
>
> zone "ab.somedomain.local" {
> type forward;
> forward only;
> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
> };
>
> But this doesn't appear to do what I want.
>
>
> If I add the above to my regular BIND servers configuration, it doesn't
> return results like it's forwarding them. (I get NXOMAIN for
> abc.ab.somedomain.local.)
>
>
> If I do a dig @10.0.0.1 abc.ab.somedomain.local from the BIND server, I
> get a proper result. (force dig to use the AD name servers directly,
> instead of relying on the forward.)
>
>
> (And yes the resolv.conf file has the ip addresses of the main internal
> BIND servers in it, and those only.)
> I've looked and while I think I'm doing it right, I'm not entirely sure.
> I figured before I beat my head against the wall for too long, I'd ask the
> real experts! :)
>
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet P.S.

[Crist Clark]

appreciated.
However, as I previously asserted, it is impossible to know how the
system will behave without testing it with real life production load
on Monday :-)
On 12/11/2021 11:18 PM, Crist Clark wrote:

Looks like you're trying to use the setup in that serverfault link.
That example only works on an internal network. I thought the
186.198.193. part was enough to make the zone unique. But your
assertion is correct: I would collide if any other administrators on
other subnets in range 193.198.186.0/24 decide to make reverse DHCP
DDNS update in the future. Thanks for the thought!

The point of the example I gave is that you are going to build your
own reverse zone inside of a zone you control on the Internet. Now
that you've given some examples, I can perhaps make it more obvious
what I'm suggesting. Your DNS zone would look something like,

$ORIGIN 192-27.186.198.193.in-addr.arpa.

@   IN  NS  domac.alu.hr [1].
@   IN  NS  bjesomar.srce.hr [2].

195 IN  PTR test-record.dhcp.slava.alu.hr [3].

$GENERATE 200-222 $ CNAME $.186.198.193.dhcp.slava.alu.hr [4].

And your DHCP configuration,

ddns-domainname "slava.alu.hr [5]";
ddns-rev-domainname "dhcp.slaval.alu.hr [6]";
zone slava.alu.hr [5]. {
primary 127.0.0.1;
key DDNS_UPDATE;
}
NOT TESTED. NO GUARANTEES. NOT SUITABLE FOR ANY GIVEN PURPOSE. YOUR
MILEAGE MAY VARY. PLEASE CONSULT YOUR PERSONAL PHYSICIAN BEFORE
STARTING ISC PRODUCTS.

 Noted. :-) I am not afraid of experimenting. But failures of the
experimental setup are perceived as my incompetence, and success taken
for granted the very next day ;-)


One other odd thing, sometimes you refer to a
"192/27.186.198.193.in-addr.arpa" zone and sometimes
"192-27.186.198.193.in-addr.arpa." Those are different names and are
not interchangeable. Both are totally fine for use in DNS, but a lot
of administrators don't like the '/' in zone names since they often
use the zone name in file names. Slashes present a problem in file
names on *nix flavored OSes. I used the dash, '-', version in my
example.


This setup is mandated from the upper level sysadmins and I cannot
control it, I can only beg them to use a hyphen as in RFC 2317 chapter
4 last paragraph, but I cannot guarantee that they will change it. It
is their arbitrary decision. :-/

Frankly, /27 is more readable, but if it creates havoc in Linux
resolver, then what the heck ...

Thank you very much again for your advice. I will post back here on
the results with your recommended zone setup.

Kind regards,
Mirsad Todorovac


Hi again,

I had some luck in making this setup work. So far, so good ...
However, there's no telling how the DHCP DDNS will function with the
new 186.198.193.dhcp. zone before Monday morning when the subsidiary
computers power up.

However, I have an odd behavior which I cannot explain: without any
change to zone a reverse resolution stopped working. The setup just
doesn't seem stable enough to work with DHCP-updated dynamic DNS in
our organization, with a lot of smartphones and wireless devices
frequently signing on and off.

The zone is:

$ORIGIN 192/27.186.198.193.in-addr.arpa.

@   IN  NS  domac.alu.hr [8].
;@  IN  NS  bjesomar.srce.hr [9].

195 IN  PTR test-record.slava.alu.hr [10].

200 IN  CNAME   200.186.198.193.dhcp.
201 IN  CNAME   201.186.198.193.dhcp.

; MT 20211211:
; Here's the magic:

$GENERATE 202-222 $ CNAME $.186.198.193.dhcp.

The command output shows that resolution succeeds, but nslookup
can't finish it for some unknown spurious reason.

root@domac:~# nslookup -query=any
195.192/27.186.198.193.in-addr.arpa.
Server: 161.53.235.3
Address:161.53.235.3#53

195.192/27.186.198.193.in-addr.arpa name =
test-record.slava.alu.hr [10].

root@domac:~# nslookup -query=ptr 193.198.186.195
Server: 161.53.235.3
Address:161.53.235.3#53

** server can't find 195.186.198.193.in-addr.arpa: NXDOMAIN

root@domac:~#

This kind of setup that sometimes works and sometimes doesn't will
make me look incompetent.
I know that BIND 9 is great open source server with lots of bells
and whistles. But right now I can't study all those and I just want
to survive, providing a solution fast enough for our uplevel
sysadmins.

The /etc/bind/named.conf.local part looks like:

zone "192/27.186.198.193.in-addr.arpa" in {
type master;
file "/etc/bind/zones/192-27.186.198.193.in-addr.arpa.db";
};

zone "186.198.193.dhcp" in {
type master;
file "/var/cache/bind/186.198.193.dhcp.db";
allow-update { key DDNS_UPDATE; };
};

What possibly could be killing the name resolution between resolving
195.192/27.186.198.193.in-addr.arpa to test-record.slava.alu.hr
[10]. and resolving 193.198.186.195 that apparently fails?

Is there a way to see more interim debugging output?

Thank you very much.

Kind regards,
Mirsad Todorovac

On 12/11/2021 10:25 AM, Mirsad Goran Todor

Re: ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet

[Crist Clark]

  NS  bjesomar.srce.hr.
>
> 195 IN  PTR test-record.slava.alu.hr.
>
> $GENERATE 200-222 $ CNAME $.186.198.193.dhcp.
>
> /etc/dhcp/dhcpd.conf has this:
>
>   ddns-domainname "slava.alu.hr";
>   ddns-rev-domainname "dhcp";
>   zone slava.alu.hr. {
>primary 127.0.0.1;
>key DDNS_UPDATE;
>   }
>   zone 186.198.193.dhcp. {
>primary 127.0.0.1;
>key DDNS_UPDATE;
>   }
>
> However, don't I have to convince people managing bjesomar.srce.hr to be
> a slave server for the "186.198.193.dhcp" zone? Or the dynamically updated
> reverse PTR record will have effect only in my local domain (which I had
> even before the entire setup), won't it?
>
> Also, I get spurious REFUSED or NXDOMAIN errors, some pass with time, so
> there must be some TTL or timeout.
>
> Kind regards,
>
> Mirsad
> On 12/11/2021 6:04 AM, Crist Clark wrote:
>
> No idea if this is the best way. It is a way.
>
> Do you control any other zone? Let’s say you own “example.com.” You can
> tell ISC DHCP to build the reverse zone at an arbitrary base name instead
> of in-addr.arpa.
>
> Configure DHCP to put the reverse records at say, “rev.example.com.” So
> you’ll get records at,
>
> 193.186.198.193.rev.example.com
> 194.186.198.193.rev.example.com
> …
>
> And in your RFC 2317-style delegation, you then enumerate another CNAME
> layer,
>
> $ORIGIN 192-27.186.198.193.in-addr.arpa.
> 193  IN CNAME 193.186.198.193.rev.example.com.
> 194  IN CNAME 194.186.198.193.rev.example.com.
> …
>
> On Fri, Dec 10, 2021 at 2:51 PM Mirsad Goran Todorovac <
> mirsad.todoro...@alu.unizg.hr> wrote:
>
>> Hello,
>>
>> I have a problem with DHCP DDNS update to BIND 9 reverse PTR zone subnet
>> that is owned by several organizations, so I can't get a direct DHCP DDNS
>> update access with a key or with hostname.
>>
>> I have been delegated domain name 192-27.186.198.193.in-addr.arpa from
>> the upper level admins, and that appears to be immutable.
>>
>> However, my subnet is 193.198.186.192/27, and DHCP only knows how to
>> perform DDNS update to 186.198.193.in-addr.arpa. (See here:
>> https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update
>> and here:
>> https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html ).
>>
>> (This setup is because we have DHCP addresses that are not over NAT, but
>> /24 subnet is shared with other organizations, even under another Minstry.)
>>
>> I want to have the effect of delegating the same database to upper level
>> under their zone name, while updating the same database under my
>> DHCP-understood zone name.
>>
>> I tried this /etc/bind/named.conf.local:
>>
>> zone "192-27.186.198.193.in-addr.arpa" in {
>> type master;
>> file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
>> };
>>
>> zone "186.198.193.in-addr.arpa" in {
>> type master;
>> file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
>> allow-update { key DDNS_UPDATE; };
>> };
>>
>> (Two zones with the same file.)
>>
>> What I got was:
>>
>> root@domac:/etc/bind# named-checkconf
>> /etc/bind/named.conf.local:49: writeable file 
>> '/var/cache/bind/192-27.186.198.193.in-addr.arpa.db': already in use: 
>> /etc/bind/named.conf.local:44
>> root@domac:/etc/bind#
>>
>> Can you please tell me is there a way to achieve the effect of the above 
>> (illegal) setup?
>> I can't change DHCP nor I know an option to tell it to accept update to 
>> 192-27.186.198.193.in-addr.arpa
>>  (it is a syntax error).
>>
>> The DHCP dhcpd.conf subnet configuration is:
>> subnet 193.198.186.192 netmask 255.255.255.224 {
>>   range 193.198.186.200 193.198.186.222; # MT 20211210
>>   option subnet-mask 255.255.255.224;
>>   option domain-name-servers 161.53.235.3, 161.53.2.70;
>>   option domain-name "slava.alu.hr";
>>   ddns-domainname "slava.alu.hr";
>>   zone slava.alu.hr. {
>>primary 127.0.0.1;
>>key DDNS_UPDATE;
>>   }
>>   zone 186.198.193.in-addr.arpa. {
>>primary 127.0.0.1;
>>key DDNS_UPDATE;
>>   }
>>   option broadcast-address 193.198.186.223;
>>   option routers 193.198.186.193;
>>   default-lease-time 43200;
>>   max-lease-time 86400;
>> }
>> Thank you very much for your time reading this mail and help.
>>
>> Kind regards,
>>
>> --
>

Re: ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet

[Crist Clark]

No idea if this is the best way. It is a way.

Do you control any other zone? Let’s say you own “example.com.” You can
tell ISC DHCP to build the reverse zone at an arbitrary base name instead
of in-addr.arpa.

Configure DHCP to put the reverse records at say, “rev.example.com.” So
you’ll get records at,

193.186.198.193.rev.example.com
194.186.198.193.rev.example.com
…

And in your RFC 2317-style delegation, you then enumerate another CNAME
layer,

$ORIGIN 192-27.186.198.193.in-addr.arpa.
193  IN CNAME 193.186.198.193.rev.example.com.
194  IN CNAME 194.186.198.193.rev.example.com.
…

On Fri, Dec 10, 2021 at 2:51 PM Mirsad Goran Todorovac <
mirsad.todoro...@alu.unizg.hr> wrote:

> Hello,
>
> I have a problem with DHCP DDNS update to BIND 9 reverse PTR zone subnet
> that is owned by several organizations, so I can't get a direct DHCP DDNS
> update access with a key or with hostname.
>
> I have been delegated domain name 192-27.186.198.193.in-addr.arpa from
> the upper level admins, and that appears to be immutable.
>
> However, my subnet is 193.198.186.192/27, and DHCP only knows how to
> perform DDNS update to 186.198.193.in-addr.arpa. (See here:
> https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update
> and here:
> https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html ).
>
> (This setup is because we have DHCP addresses that are not over NAT, but
> /24 subnet is shared with other organizations, even under another Minstry.)
>
> I want to have the effect of delegating the same database to upper level
> under their zone name, while updating the same database under my
> DHCP-understood zone name.
>
> I tried this /etc/bind/named.conf.local:
>
> zone "192-27.186.198.193.in-addr.arpa" in {
> type master;
> file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
> };
>
> zone "186.198.193.in-addr.arpa" in {
> type master;
> file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
> allow-update { key DDNS_UPDATE; };
> };
>
> (Two zones with the same file.)
>
> What I got was:
>
> root@domac:/etc/bind# named-checkconf
> /etc/bind/named.conf.local:49: writeable file 
> '/var/cache/bind/192-27.186.198.193.in-addr.arpa.db': already in use: 
> /etc/bind/named.conf.local:44
> root@domac:/etc/bind#
>
> Can you please tell me is there a way to achieve the effect of the above 
> (illegal) setup?
> I can't change DHCP nor I know an option to tell it to accept update to 
> 192-27.186.198.193.in-addr.arpa
>  (it is a syntax error).
>
> The DHCP dhcpd.conf subnet configuration is:
> subnet 193.198.186.192 netmask 255.255.255.224 {
>   range 193.198.186.200 193.198.186.222; # MT 20211210
>   option subnet-mask 255.255.255.224;
>   option domain-name-servers 161.53.235.3, 161.53.2.70;
>   option domain-name "slava.alu.hr";
>   ddns-domainname "slava.alu.hr";
>   zone slava.alu.hr. {
>primary 127.0.0.1;
>key DDNS_UPDATE;
>   }
>   zone 186.198.193.in-addr.arpa. {
>primary 127.0.0.1;
>key DDNS_UPDATE;
>   }
>   option broadcast-address 193.198.186.223;
>   option routers 193.198.186.193;
>   default-lease-time 43200;
>   max-lease-time 86400;
> }
> Thank you very much for your time reading this mail and help.
>
> Kind regards,
>
> --
> Mirsad Goran Todorovac
> Academy of Fine Arts | Faculty of Graphic Arts
> University of Zagreb
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: Recursion setting for bind9

[Crist Clark]

Maybe a little confused here, but BIND won’t try another server if it gets
an answer. It will only try another forwarder if the query fails.

On Wed, Sep 29, 2021 at 12:21 AM Sonal Pahuja 
wrote:

> Hi All,
>
>
>
> Is there any option to set recursion =1 in named.conf file for the zone. I
> just want bind9 to do recursion only once.
>
> If bind9 receives answer from one of the forwarders then it should not do
> recursion (forward query) to any other forwarder IP.
>
>
>
> Below is my snapshot of my named.conf file
>
>
>
> options {
>
> listen-on port 53 { any; };
>
> listen-on-v6 port 53 { any; };
>
> directory   "/var/named";
>
> dump-file   "/var/named/data/cache_dump.db";
>
> statistics-file "/var/named/data/named.stats";
>
> memstatistics-file "/var/named/data/named_mem_stats.txt";
>
> allow-query { localhost; !blocked; allowed; };
>
> //  allow-query { localhost; };
>
> recursion yes;
>
> zone-statisticsyes;
>
> dnssec-enable no;
>
> dnssec-validation no;
>
> auth-nxdomain no;
>
> // additional-from-auth no;
>
>  // additional-from-cache no;
>
> /* Path to ISC DLV key */
>
> bindkeys-file "/etc/named.iscdlv.key";
>
>
>
> managed-keys-directory "/var/named/dynamic";
>
>
>
>
>
> };
>
> zone "e164.arpa" IN {
>
> type forward ;
>
> forwarders { 127.0.0.1 port 49153;   199.165.24.21 port 49153; };
>
> forward only;
>
> };
>
>
>
> Regards,
>
> Sonal
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: forwarding zone setup from a BIND slave (without recursion?)

[Crist Clark]

So why doesn’t it work to make your limited server authoritative for the
root and only forward the zones you want? Anything that isn’t in a
forwarded zone does not exist (except the root itself).

On Sat, Apr 17, 2021 at 11:07 PM Marki  wrote:

>
> On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote:
>
>
> My situation is due to a security requirement.  We have DNS servers at our
> site running BIND that allow recursion, but I’ve been requested to set up
> some additional DNS servers for another project that is expected to *
> *only** access the data that we’re authoritative for.  And of course ….
> there’s a chance that it might need to look up one or two external zones.
> Essentially, what I really need is a recursive whitelist that doesn’t tell
> BIND what clients are allowed to do recursive lookups, but to limit BIND to
> only allow recursive lookups on a very small list of allowed domains.
>
>
>
> I was trying to set up a forwarding zone to forward queries to our DNS
> servers that do allow recursion, but as I discovered (and as was discussed
> earlier in the thread), if recursion is not allowed, then forwarding is
> also not allowed.  I had tried setting the “allow-recursion” field to
> “localhost” and setting up a forward zone to forward to 127.0.0.1, but that
> didn’t work either.
>
> Hello,
>
> So they do _not_ only look up internal/authoritative zones, but external
> ones as well. (It's always the exceptions that kill you.)
>
> I think we have previously established that there is not a good way to do
> whitelisting using Bind, see the thread "Authority and forwarding, but not
> recursion/iteration".
>
> If you can live with non-allowed zones returning SERVFAIL (instead of
> NXDOMAIN for example), then using a recursive service with a bogus global
> forwarder and static stubs pointing to the authoritative/non-recursive
> service might do the trick.
>
> You might also be able to leverage RPZ if there are no complex conditions
> associated to your rules (everyone will have the same white/blacklists).
> You configure passthrough for the allowed zones and deny the rest.
>
> Alternatively, there is dnsdist which, while being a load-balancer, could
> be considered the swiss army knife of DNS filtering.
>
> Finally, some firewalls like Fortigates provide a "DNS filter" that lets
> you define custom white and blacklists. Palo Altos currently are not able
> to whitelist AFAIK.
>
> Best regards,
>
> Marki
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: Authority and forwarding, but not recursion/iteration

[Crist Clark]

Where is it sending recursive queries if it owns the root?

On Sun, Mar 7, 2021 at 3:06 AM Marki  wrote:

> I tried that. When you configure no global forwarders it's going to
> recurse because recursion needs to be enabled for the individual forwarded
> zones to work. You'd have to specify a fake global forwarder which looks
> like a hack.
>
>
> On March 7, 2021 10:09:49 AM GMT+01:00, Crist Clark <
> cjc+bind-us...@pumpky.net> wrote:
>>
>> Two views. The view that does not do internet DNS claims authority for
>> the root and does not global forward. The entire DNS is just the zones
>> defined in the view, which can be authoritative or forwarded. The other
>> view has the global forward-only to upstream resolvers.
>>
>> On Sat, Mar 6, 2021 at 3:34 PM Marki  wrote:
>>
>>> I'm not sure:
>>>
>>> > Some clients should be able to resolve authoritative local zones as
>>> well as some forwarded zones.
>>>
>>> And only that. "forward only;" doesn't cut it, in case you mean the
>>> global option. That would still forward everything else somewhere else. The
>>> requirement is to _only_ resolve local stuff for some clients.
>>> On 3/6/2021 8:48 PM, Crist Clark wrote:
>>>
>>> forward only;
>>>
>>> On Fri, Mar 5, 2021 at 5:19 PM Marki  wrote:
>>>
>>>> Hello,
>>>>
>>>> I am seeking a combination of either a combined configuration on one,
>>>> or
>>>> a config of several different DNS servers together to achieve the
>>>> following:
>>>> * Some clients should be able to resolve authoritative local zones as
>>>> well as some forwarded zones.
>>>> * Other clients should be able to resolve all of that _plus_ be able to
>>>> make recursive queries to the internet (or use a global forwarder).
>>>> All hosts use the same DNS servers, this should not be made about the
>>>> clients but rather be configurable on the server.
>>>>
>>>> Now the problems are the following:
>>>> * Since I need forwarders I can't turn off recursion.
>>>> * Since I can't turn off recursion I can't prevent it to go and try to
>>>> resolve from root DNS.
>>>>
>>>> How do I do one (local authority and forwarders) but not the other
>>>> (iterative lookups on the Internet)?
>>>>
>>>> Thanks,
>>>>
>>>> Marki
>>>>
>>>> ___
>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>>> unsubscribe from this list
>>>>
>>>> ISC funds the development of this software with paid support
>>>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>>>> information.
>>>>
>>>>
>>>> bind-users mailing list
>>>> bind-users@lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>>
>>>> ___
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>> unsubscribe from this list
>>>
>>> ISC funds the development of this software with paid support
>>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>>> information.
>>>
>>>
>>> bind-users mailing list
>>> bind-users@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: Authority and forwarding, but not recursion/iteration

[Crist Clark]

Two views. The view that does not do internet DNS claims authority for the
root and does not global forward. The entire DNS is just the zones defined
in the view, which can be authoritative or forwarded. The other view has
the global forward-only to upstream resolvers.

On Sat, Mar 6, 2021 at 3:34 PM Marki  wrote:

> I'm not sure:
>
> > Some clients should be able to resolve authoritative local zones as well
> as some forwarded zones.
>
> And only that. "forward only;" doesn't cut it, in case you mean the global
> option. That would still forward everything else somewhere else. The
> requirement is to _only_ resolve local stuff for some clients.
> On 3/6/2021 8:48 PM, Crist Clark wrote:
>
> forward only;
>
> On Fri, Mar 5, 2021 at 5:19 PM Marki  wrote:
>
>> Hello,
>>
>> I am seeking a combination of either a combined configuration on one, or
>> a config of several different DNS servers together to achieve the
>> following:
>> * Some clients should be able to resolve authoritative local zones as
>> well as some forwarded zones.
>> * Other clients should be able to resolve all of that _plus_ be able to
>> make recursive queries to the internet (or use a global forwarder).
>> All hosts use the same DNS servers, this should not be made about the
>> clients but rather be configurable on the server.
>>
>> Now the problems are the following:
>> * Since I need forwarders I can't turn off recursion.
>> * Since I can't turn off recursion I can't prevent it to go and try to
>> resolve from root DNS.
>>
>> How do I do one (local authority and forwarders) but not the other
>> (iterative lookups on the Internet)?
>>
>> Thanks,
>>
>> Marki
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: Authority and forwarding, but not recursion/iteration

[Crist Clark]

forward only;

On Fri, Mar 5, 2021 at 5:19 PM Marki  wrote:

> Hello,
>
> I am seeking a combination of either a combined configuration on one, or
> a config of several different DNS servers together to achieve the
> following:
> * Some clients should be able to resolve authoritative local zones as
> well as some forwarded zones.
> * Other clients should be able to resolve all of that _plus_ be able to
> make recursive queries to the internet (or use a global forwarder).
> All hosts use the same DNS servers, this should not be made about the
> clients but rather be configurable on the server.
>
> Now the problems are the following:
> * Since I need forwarders I can't turn off recursion.
> * Since I can't turn off recursion I can't prevent it to go and try to
> resolve from root DNS.
>
> How do I do one (local authority and forwarders) but not the other
> (iterative lookups on the Internet)?
>
> Thanks,
>
> Marki
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: [RESOLVED] Re: No response from localhost with "allow-query { any; };"

[Crist Clark]

>From release notes:

Notes for BIND 9.16.1

Known Issues
UDP network ports used for listening can no longer simultaneously be used
for sending traffic. An example configuration which triggers this issue
would be one which uses the same address:port pair for listen-on(-v6)
statements as for notify-source(-v6) or transfer-source(-v6). While this
issue affects all operating systems, it only triggers log messages (e.g.
“unable to create dispatch for reserved port”) on some of them. There are
currently no plans to make such a combination of settings work again.

Also, using fixed sourt ports is at worst considered harmful, at best
considered a quaint reminder of the ol' days of stateless firewalls.
Generally, if you need to do that, you are doing something wrong.


On Fri, Sep 4, 2020 at 2:25 AM Axel Rau  wrote:

>
>
> Am 01.09.2020 um 22:28 schrieb Axel Rau :
>
> tcp queries are being answered, but udp queries receive no response.
> This is independent of client location (local, remote).
>
> A ktrace shows 8 bytes are written on fd 89, the 8 bytes read on fd 88.
> The next read gets an errno 35 (see below).
>
>
> Commenting these out, seems to resolve the issue:
>
> query-source address  91.216.35.21;
> notify-source   91.216.35.21 port 53;
> transfer-source   91.216.35.21 port 53;
>
> query-source-v6 address2a05:bec0:26:5::71;
> notify-source-v6 2a05:bec0:26:5::71 port 53;
> transfer-source-v6 2a05:bec0:26:5::71 port 53;
>
> Queries to localhost shows that the response does not come from localhost:
>
> root@ns5:/var/log # dig localhost @localhost
> ;; reply from unexpected source: 91.216.35.21#53, expected 127.0.0.1#53
>
> ;; reply from unexpected source: 91.216.35.21#53, expected 127.0.0.1#53
>
> ;; reply from unexpected source: 91.216.35.21#53, expected 127.0.0.1#53
>
>
> ; <<>> DiG 9.16.6 <<>> localhost @localhost
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
> No issue with remote queries.
>
> Questions:
>
> What has query-source address to do with a query response?
> Why does the issue not happen on another server (same config, same OS
> version) ?
>
> Axel
> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: DNSSEC migration sanity check

[Crist Clark]

Not sure I understand why you need to do anything except change the
authoritative NS records in the zone and in the delegation at the
registrar. You also only really need to decrease the TTL on the NS
records, not all of the records in the zone. Why touch any keys and
the corresponding DS records?

Are we missing some complication in your deployment?

On Wed, Aug 19, 2020 at 11:44 AM John W. Blue via bind-users
 wrote:
>
> We are in the process of moving from one IPAM vendor to another.
>
>
>
> All of our zones are DNSSEC signed and the TTL’s have been lowered to 300 
> seconds.
>
>
>
> At a high level, the playbook is to update the registrar with names/IP 
> addresses of the new servers and update the DSKEY.  Depending on the time of 
> the day that the cutover actually happens at we know the process to request 
> of the registrar an out of band data push so the new servers will be seen by 
> the open Internet.
>
>
>
> A suggestion have been put forth that we should unsign our zones prior to 
> migration but I am skeptical of the benefits of doing so.
>
>
>
> Are we missing something obvious?
>
>
>
> John
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: TXT with dot in NAME for ACME via dynamic update

[Crist Clark]

It looks like it worked. Your test is asking for A records, not the TXT
records for the name. Try,

$ dig _acme-challenge.imap.lrau.net. txt @localhost


On Sat, Mar 14, 2020 at 10:31 AM Axel Rau  wrote:

>
>
> Am 14.03.2020 um 18:14 schrieb Chuck Aurora :
>
> it seems, the dynamic update protocol does not allow things like
> _acme-challenge.some-host.some.domain TXT
> "tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0"
> because there is no zone
> some-host.some.domain
>
>
> I am pretty sure that is not correct, but we can't help unless you
> show your work.  If you need to specify the zone to update, you can
> and should.  BIND's nsupdate(8) and other dynamic DNS clients allow
> you to do this.
>
>
> With this file
> - - -
> server localhost
> debug
> zone lrau.net
> ttl 3600
> add _acme-challenge.imap.lrau.net.  3600 TXT
>  "tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0"
> show
> send
> answer
> - - -
> I get:
> - - -
> # nsupdate -k /usr/local/etc/namedb/dns-keys/ddns-key.conf
> ~/admin/ns-update-example.txt
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> ;; ZONE SECTION:
> ;lrau.net. IN SOA
>
> ;; UPDATE SECTION:
> _acme-challenge.imap.lrau.net. 3600 IN TXT
> "tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0"
>
> Sending update to ::1#53
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  4
> ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;lrau.net. IN SOA
>
> ;; UPDATE SECTION:
> _acme-challenge.imap.lrau.net. 3600 IN TXT
> "tR0VhMRfb4v5WsctEgoD3aWNRJ73n2wqn9hlTPE9pA0"
>
> ;; TSIG PSEUDOSECTION:
> ddns-key. 0 ANY TSIG hmac-sha256. 1584206515 300 32 . . . 4 NOERROR 0
>
>
> Reply from update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  4
> ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;lrau.net. IN SOA
>
> ;; TSIG PSEUDOSECTION:
> ddns-key. 0 ANY TSIG hmac-sha256. 1584206515 300 32 . . . 4 NOERROR 0
>
> Answer:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  4
> ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;lrau.net. IN SOA
>
> ;; TSIG PSEUDOSECTION:
> ddns-key. 0 ANY TSIG hmac-sha256. 1584206515 300 32 . . . 4 NOERROR 0
>
> # dig _acme-challenge.imap.lrau.net.  @localhost
>
> ; <<>> DiG 9.16.0 <<>> _acme-challenge.imap.lrau.net. @localhost
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6153
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 404b9f34e94920a4ef3dd3065e6d14308acdeabfe0744b88 (good)
> ;; QUESTION SECTION:
> ;_acme-challenge.imap.lrau.net. IN A
>
> ;; AUTHORITY SECTION:
> lrau.net. 3600 IN SOA ns4.lrau.net. hostmaster.lrau.net. 2020030850 86400
> 7200 604800 3600
>
> ;; Query time: 0 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Sat Mar 14 17:28:16 UTC 2020
> ;; MSG SIZE  rcvd: 145
>
> (pki_dev_p37) [root@hermes /usr/local/py_venv/pki_dev_p37/src]#
>
> Axel
> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

BIND Workaround for Broken DNS

[Crist Clark]

We have a service vendor with broken DNS. It looks like a well known
problem of F5 load balancers. For the name,

 efederation.wip.ceridian.com (you get redirected there from
https://iam.ceridian.com)

The DNS "servers" return an answer for a A request, but when you ask
for any other record type, they send a name-does-not-exist status,
"NXDOMAIN." Once our caching BIND servers get the NXDOMAIN response,
the A record info doesn't matter anymore. They return NXDOMAIN for a A
record query too.

Yes, yes, I know the Right Answer is to get the vendor to fix their
load balancer. But we get the "it works when we're at home," "it works
with Google/Cloudflare DNS," "it works on my phone when I use mobile
data," so our DNS server must be broken. We have to make it work while
we convince the vendor to fix it.

Is there any way to get BIND to work around this brokenness? Something
like a way to completely turning off caching for a zone? Other ways to
deal with it aside from setting up our own authoritative zone for the
name? Seems like RPZ could do it in similar fashion with just a record
or two. Unfortunately, we don't have an existing RPZ deployed across
the enterprise so it's the same level of effort.

And how can we be the only customer with this problem? Seems like
anyone dual stacked (even unknowingly so) and a caching DNS server
that follows the rules would be getting killed by the  lookups.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DDNS with extra vhosts...

[Crist Clark]

This isn’t really a BIND or DNS problem. There is not a standard way to do
this.

If you’re going for some kind of automation or orchestration of these
services, there are a bunch of different places to build this in, depending
on the tools you are using.

You did mention ISC DHCP. One approach would be to use the server-side
hooks when a lease is created  or renewed. You could add a script that
creates what ever additional names you want.

On Sun, Sep 29, 2019 at 10:22 AM John Robson via bind-users <
bind-users@lists.isc.org> wrote:

> Hi all,
>
> I've set up both ISC dhcpd and ISC bind to provide relevant services to a
> virtualised test lab.  In the test lab obviously boxes will be brought up
> and down fairly frequently, and I'm aiming to minimise the amount of effort
> that this takes our users.
>
> So - the machines get an IP address and dhcpd updates bind, so a specific
> internal domain gets updated - let's use example.orghere for ease of
> reading.
>
> That all works (after a little fight with permissions).
> I set up a machine with a hostname of 'foo' and there is an automagic DNS
> entry `foo.example.org`.
>
> BUT - what I'd like to do is have `*.foo.example.org` (or even a specific
> listing of subdomains) point to that IP as well - to enable the various
> vhost based services on the test machines to be accessed without having to
> mess with local hosts files or further mess with DNS each time.
>
> e.g. test.foo.example.org should point to the same IP as foo.example.org 
> (heck,
> could even be a cname)
>
> Is there some simple configuration I am missing - or is this not possible?
> Is there a better way to get to where I want to be*?
>
> Cheers,
>
> John
>
>
> * Previously we had all the test boxes in one /24, so we had `lab123` for
> the box whose IP ended in 123... but we're now in a /23, and that gets a
> lot messier to handle with fixed names (not particularly keen on the idea
> of test341 being for the top half ending in 341-256=85 - nor am I keen on 5
> digit test ids...)
>
> --
>
> *John Robson*
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: RPZ and forward zone trouble

[Crist Clark]

In order to make the determination whether to apply an rpz-nsip rule,
the DNS server must have the NS records and their corresponding A
records. In a recursive resolver, it would have had to lookup said NS
and A records to find the answer to the query, so they are cached and
available. In a forwarding resolver, it does not need to look up the
intermediate NS records to answer the query. It does not have the NS
records available.

You basically need your forwarder to act like a recursive resolver in
order for it to get the info in needs. Looks like BIND follows its
directive to be a forwarder as the higher calling, and doesn't do the
extra look ups necessary to get the answers it could use for the RPZ
policies. However, if they are cached and available, it will go ahead
and use them.

I think the right answer is that if you want full capabilities for
RPZ, you need full recursive resolver functionality.

(Just a BIND user explaining how I understand these features to work.
I may be way off. Also, you should be sure to read the following if
you have not already. I may not be correctly understanding your
explanation, and this document is specifically about limitations and
unexpected behaviors of this functionality,
https://kb.isc.org/docs/aa-00862
)

On Mon, Mar 25, 2019 at 4:45 PM Miguel Mucio Santos Moreira
 wrote:
>
> Lee, thanks for your quick answer.
> I applied the policy based on rpz-nsip trigger instead of mg.gov.br QNAME 
> because of some others situations in my environment. Like I said earlier, the 
> doubt is why when there's no forward zone the trigger works properly? In my 
> opinion it should'nt have different behaviour just because of forward zone, 
> at least I can't imagine why this is happening.
> The Bind version deployed is 9.11.4, I was imagining It could be a bug, and 
> It seems bind 9.12 version has a fix related to this problem, but I'm not 
> sure.
>
>  thanks one more time.
>
>
>
> Miguel Moreira
> Gerente
> DPR/SRE/GSR - Gerência de Serviços de Rede
> +55(31)3339-1401
> PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais
>
>
> Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é 
> dirigida, podendo conter informação sigilosa e legalmente protegida. O uso 
> impróprio será tratado conforme as normas da empresa e a legislação em vigor. 
> Caso não seja o destinatário, favor notificar o remetente, ficando proibidas 
> a utilização, divulgação, cópia e distribuição. Em Segunda, Março 25, 2019 
> 18:37 -03, Lee  escreveu:
>
> On 3/25/19, Miguel Mucio Santos Moreira wrote:
> >
> > Hello everybody!
>
> Hi!
>
> > I have a problem with DNS-RPZ and forward zone working together.
> > I've created a rpz zone with the following trigger on my recursive DNS
> > Server:
> > 18.0.0.198.200.rpz-nsip IN CNAME rpz-passthru.
>
> Which means anybody can answer with a 200.198.0.0/18 address and it
> will be accepted. .. probably not what you want.
>
> > It means any query response comming from a DNS Server which IP address
> > matching with the any IP address at entire CIDR block 200.198.0.0/18 will be
> > answered with rpz-passthru
> > It works perfectly for any domain hosted in my Authoritative DNS Servers.
> > But when I apply on my recursive RPZ DNS Server a forward zone for those
> > domains hosted on my Authoritative DNS Servers the problems appear and it is
> > very weird.
> >
> > I have a mg.gov.br domain
>
> I'd go with
>
> mg.gov.br IN CNAME rpz-passthru.
> -- it's your domain so hopefully you can trust whatever answers it gives
> 18.0.0.198.200.rpz-nsip IN CNAME .
> -- nobody else gets to answer with your address space
>
> Regards,
> Lee
>
> > and its NS Servers are zeus.prodemge.gov.br
> > (200.198.5.13), titanio.prodemge.gov.br (200.198.5.5), tupan.prodemge.gov.br
> > (200.198.4.4) and jupiter.prodemge.gov.br (200.198.5.2).
> > If I perform a dig at my workstation using Recursive DNS with RPZ looking
> > for any record in mg.gov.br domain, rpz-passthru policy is not applied,
> > however if I perform a dig looking for any record in prodemge.gov.br domain
> > and after that I perform the same dig before it works properly.
> >
> >
> > Note: Recursive DNS Servers and Authoritative DNS Servers are not the same.
> >
> > As workaround solution I applied 4 rpz-nsdname triggers above that one
> > mentioned in the begining this email with my authoritative name servers with
> > rpz-passthru policy.
> > titanio.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru.
> > jupiter.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru.
> > tupan.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru.
> > zeus.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru.
> >
> > I would like to understand why it didn't work without workaround solution,
> > anyone has any idea about it?
> >
> > Thanks in advance
> > --
> >
> > Miguel Moreira
> > Gerente
> > DPR/SRE/GSR - Gerência de Serviços de Rede
> > +55(31)3339-1401
> > PRODEMGE - Companhia de Tecnologia da Informação do Estado de 

Re: BIND 9.11.5-P4 can't do ipv6 recursion

[Crist Clark]

Local firewall rules on the server? Did you have to make any firewall
changes for IPv4? Did you do the same for IPv6?

On Mon, Mar 18, 2019 at 10:20 PM Mark Andrews  wrote:
>
> On the server run "dig version.bind txt ch @::1”.  This should get a response 
> and
> work from there.  e.g. "dig version.bind txt ch @other_addresses”, then try 
> from
> different machines.  Named has had IPv6 support for 2 decades now.  The 
> problem
> will almost certainly be with the environment not the server.
>
> > On 19 Mar 2019, at 2:33 pm, celia <66183...@qq.com> wrote:
> >
> > Hello ALL,
> >  I set up a  recursion DNS in our college. It works well in ipv4 
> > request,but can not resolve ipv6 request. The named.conf file is as follows:
> >
> > acl "trusted"{202.115.253.0/24;202.112.16.0/24;202.112.14.0/23;};
> > acl "ipv6" {2001:da8:6000::/48;};
> >
> > options{
> > directory "/usr/local/named/etc/";
> > pid-file "/var/run/named/named.pid";
> > statistics-file "/var/named/data/named_stats.txt";
> >
> > listen-on-v6 {any;};
> > recursion yes;
> > allow-recursion {trusted;ipv6;};
> > recursive-clients 2;
> > tcp-clients 500;
> > allow-query-cache {trusted;ipv6;};
> > dump-file "/var/named/data/cache_dump.db";
> > };
> >  I have tried some methods to solve this problem,such as stop the firewall, 
> > chanege "listen-on-v6"option to "listen-on-v6{my ipv6 address;}",it does 
> > not work. i can ping my DNS'ipv6 address,but when using lookup,it shows 
> > time out ...
> > the system log shows :listening on IPv6 interfaces,port 53,but i am sure 
> > port 53 does not response the request.
> >
> > thanks for help
> > best regards
> > celia
> > 2019-03-19
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re:

[Crist Clark]

You need to explicitly define the root zone. Last I knew, BIND still
gets the root zone hardcoded into the executable and will try to Do
the Right Thing and find the root on its own even if the administrator
does not define one or provide hints.

You need something like,

zone "." {
type master;
file "empty.db";
};


On Tue, Feb 19, 2019 at 10:29 AM Roberto Carna  wrote:
>
> Dear Matus and Kevin, please tell me if it's OK if I do thsi:
>
> named.conf:
> include "/etc/bind/named.conf.default-zones";
>
> named.conf.default-zones:
> recursion yes;
> zone "teamviewer.com" {
> type forward;
> forwarders { 8.8.8.8; };
> };
>
> named.conf.local:
> 
>
> I define "recursion yes" in named.conf.default-zones.
>
> Thanks again, regards !!!
>
> El mar., 19 feb. 2019 a las 15:13, Matus UHLAR - fantomas via bind-users 
> () escribió:
>>
>> On 19.02.19 09:45, Roberto Carna wrote:
>> >Dear Kevin, I am sorry but I didn't see your past response.
>> >
>> >Please can you show me with an example what you say: "Define root zone.
>> >Delegate teamviewer.com from root. Define teamviewer.com as 'type forward'".
>> >
>> >An also what is the benefit in defining a root zone with the teamviewer.com
>> >delegated into it??? Because I put to work this zone just as a forward
>> >zone, without a root zone definition.
>>
>> the benefit is it does exactly what you want.
>> the "teamviewer.com" zone of type forward causes DNS resolution of 
>> teamviewer.com
>> domain.
>> the root zone effectively disables everything else (because bind thinks
>> nothing else exists).
>>
>> >El lun., 18 feb. 2019 a las 17:00, Kevin Darcy ()
>> >escribió:
>> >
>> >> I've already posted a solution for this. Basically, "Define root zone.
>> >> Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
>> >> forward'".
>> >>
>> >> "Recursion yes" is implied. No views necessary. It doesn't make any sense
>> >> anyway, to have the same match-clients list for all of one's views, since
>> >> the first one matched is the one that's used.
>> >>
>> >> Did you not see my response, or did you perhaps dislike the approach I
>> >> suggested?
>> >>
>> >> There was some subsequent discussion about not relying on DNS resolution
>> >> as one's *only* control over what sites one's clients can or cannot 
>> >> access.
>> >> While I agree with that, my position is that there's nothing wrong with
>> >> controlling DNS resolution, in addition to other controls.
>>
>> --
>> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
>> Warning: I wish NOT to receive e-mail advertising to this address.
>> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>> M$ Win's are shit, do not use it !
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: EDNS Compliance

[Crist Clark]

In SRX speak:

  # set security alg dns disable

To verify status of DNS and other ALGs:

  show security alg status

The DNS ALG is one of those enabled by default and must be explicitly
disabled to turn it off.


On Fri, Jan 18, 2019 at 1:14 PM N. Max Pierson 
wrote:

> The 2 servers that pass the check are behind an old Cisco FWSM so I know
> it at least works. Hopefully that code carried over to the ASA and won't
> give us any problems but if it does, I have the option of moving these
> servers directly to the internet and I can configure iptables for any
> filtering we need.
>
> As far as any option in the SRX, I do not see any configuration options to
> disable the version check for EDNS as you suggested. I have a couple of
> posts on Juniper forms/mailing lists to see if I get anyone familiar with
> these options but for the moment we are just using the SRX as a packet
> filter with no ALGs so we may be out of luck.
>
> Regards,
> Max
>
> Regards,
> Max
>
> On Fri, Jan 18, 2019 at 3:07 PM Mark Andrews  wrote:
>
>> I can’t remember if Cisco ASA has a similar issue.  Checkpoint does have
>> similar
>> issues (EDNS version != 0 and EDNS flags) last time I checked.
>> Checkpoint were
>> thinking of changing the defaults.  You just need to turn off the setting
>> on the
>> Juniper.  It really shouldn’t be on by default as it doesn’t do anything
>> useful.
>>
>> > On 19 Jan 2019, at 7:52 am, N. Max Pierson 
>> wrote:
>> >
>> > I was just trying to figure out how I could log this but since the
>> logging would only probably show if something didn't match udp 53 on the
>> server IP it probably wouldn't match the block-any catch-all log I
>> configured. I will certainly bring this up to our Juniper rep but in the
>> meantime, I have a spare Cisco ASA I am going to migrate these subnets to
>> and see if that fixes the timeouts we are experiencing.
>> >
>> >  Mark, thank you for your explanation. And if anyone knows someone at
>> Juniper you may want to mention this to them as if they do not fix it
>> before flag day, a lot of queries will be broken.
>> >
>> > Regards,
>> > Max
>> >
>> > On Fri, Jan 18, 2019 at 2:42 PM Mark Andrews  wrote:
>> > This is the signature of a Juniper firewall which drops EDNS version !=
>> 0 and
>> > packet with a NSID option present.  Dropping EDNS version != 0 just
>> breaks
>> > future interoperability and as already impacted of EDNS development as
>> the
>> > RFC 6891 would have included a EDNS version bump except for these stupid
>> > firewalls dropping EDNS version != 0.  NSID is used to identify a server
>> > in a anycast cluster and the information is not returned unless the
>> operator
>> > has configured the server to return it.  There is no need for a
>> firewall to
>> > drop queries with these properties.
>> >
>> > Please file a bug report with Juniper.
>> >
>> > Mark
>> >
>> > > On 19 Jan 2019, at 4:02 am, N. Max Pierson 
>> wrote:
>> > >
>> > > Hi List,
>> > >
>> > > I am trying to ensure our Bind servers comply with EDNS for the
>> upcoming Flag Day (https://dnsflagday.net/). I am somewhat ignorant to
>> EDNS but from what I have read, the information is somewhat conflicting as
>> some documentation states EDNS is not a record that you configure in your
>> zone file then other sites refer to some sort of OPT record you can
>> configure. So my first question is which of the documentation is correct
>> from what I have read? Is it DNS server functionality that supports EDNS or
>> do you also have to configure something in the zone files?
>> > >
>> > > Also, I have 4 (well 5 counting the master that isn't queryable)
>> nameservers with multiple domains served on them. When I run one of my
>> primary domains through the ISC EDNS tool, it comes back as 2 out of the 4
>> are failing EDNS queries.They are all on the same version of Bind
>> (9.8.2rc1) and they are all slaves of the master so they should all have
>> the same records. Can anyone please explain what I need to do to resolve
>> the timeouts listed on the ISC testing tool?
>> > >
>> > > Here is what the tool says ...
>> > >
>> > >
>> > > venyu.com. @208.79.48.30 (ns4.venyu.com.): dns=ok edns=ok
>> edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok
>> docookie=ok edns512tcp=ok optlist=timeout
>> > >
>> > > venyu.com. @69.2.33.250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>> > > venyu.com. @2604:d800:12::250 (ns1.venyu.com.): dns=ok edns=ok
>> edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok
>> docookie=ok edns512tcp=ok optlist=ok
>> > >
>> > > venyu.com. @69.2.63.250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>> > > venyu.com. @2604:d800:13::250 (ns3.venyu.com.): dns=ok edns=ok
>> edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok
>> docookie=ok edns512tcp=ok optlist=ok
>> > >

Re: 2 Questions - forward zone and DNS firewalling

[Crist Clark]

On Thu, Oct 25, 2018 at 2:57 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

> On 10/25/18 2:34 PM, N6Ghost wrote:
>
[snip]

>
> > next, we where a bind shop but switched to infoblox for some stuff and
> > now out grew it. and are going back to bind.
> >
> > but we started using the dns firewall part of it and they actually
> > really liked it. any ideas for domain blacklisting? via some sort of
> > feed etc? what is everyone doing for that sort of thing?
>
> Response Policy Zone(s) are what you want.  I thought that's how
> Infoblox did it themselves.


Yes, Infoblox’s DNS implementation is a wrapper around BIND and DNS
Firewall is just straight up BIND RPZ underneath. If you still have
Infoblox around, you can dump the BIND configuration at the CLI and see
exactly what is going on underneath it all.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: how to dynamically change/update (own private) domain record

[Crist Clark]

Not exactly sure what you are doning since we don’t see what records you’re
trying to add, but it sounds like you are “attempting to add a CNAME
alongside a non-CNAME” which doesn’t make sense and will fail.

A CNAME means "use the records for this other name whenever this name is
queried.” It doesn’t make sense to have any other records[*] for a domain
name once you use a CNAME with it.

[*] DNSSEC and possibly some other “hidden” records excepted.

On Sun, Sep 23, 2018 at 6:41 AM lejeczek via bind-users <
bind-users@lists.isc.org> wrote:

> On 22/09/18 21:58, Mark Andrews wrote:
> > The update policy rules you have don’t allow the apex to be updated.
> Change the rule types to “subdomain” and the name fields to “dom.local”.
> >
> fantastycznie!
>
> many! thanks
>
> may I also ask why cname does not work in my setup?
>
> client @0x7f4d84094190 10.3.1.100#12046/key nsupdate_key: updating zone
> 'dom.local/IN': attempt to add CNAME alongside non-CNAME ignored
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RPZ Still Doing Recursive Lookups

[Crist Clark]

I am seeing that even with a zone included in an RPZ, the BIND server is
still going out to the Internet to resolve the name. I was hoping the RPZ
entry would stop processing short of that.

I have some.bad.domain.tld returning NODATA. The client is getting the
response I expect. The SOA is for the RPZ. I see it being logged as an RPZ
response. That's all good.

But what is not good is that the server is still sending a query for
some.bad.domain.tld upstream to its forwarder. I do not want that. I
expected the RPZ to stop that.

Is this expected behavior? Why is it doing it? Is there a way to stop it?

BIND 9.9.2.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: RPZ Errors

[Crist Clark]

On Tue, Nov 12, 2013 at 09:14:24AM -0500, Alan Clegg wrote:
 
 On Nov 12, 2013, at 12:13 AM, Crist Clark cjc+bind-us...@pumpky.net wrote:
 
  From the initial mail: This is BIND 9.9.2 (Infoblox 6.7.3).
  
  No huge increase in resource usage noted.
 
 Has the vendor in question provided a response?
 
 Having worked on Frankenstein versions of BIND in the past (Hi, Redhat!), I?d 
 be leery of answering this question as an ?outsider?.  Certainly not with an 
 authoritative answer.

I have an open ticket with their support. I only came to the list after
not getting a lot of help. My tech seems to think the db_find() messages
mean the server cannot resolve the names in question like there is a
firewall or something blocking queries. But I can resolve the names when
I query directly and the firewall is not blocking any DNS from the servers
in question.

I vaguely remember seeing something about the RPZ checks only using cached
data for checks and not doing active lookups for things like NS records for
performance reasons. I think it was on an ISC blog or something, not in
any official manual. That's my suspicion of what db_find() failures mean.
It couldn't find info in the cache.

What I'd actually really like here is someone to give me a RTFM post with
a pointer to the FM for RPZ error messages and algorthms if one exists. 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: RPZ Errors

[Crist Clark]

From the initial mail: This is BIND 9.9.2 (Infoblox 6.7.3).

No huge increase in resource usage noted.

On Mon, Nov 11, 2013 at 1:47 AM, Phil Mayers p.may...@imperial.ac.ukwrote:

 On 08/11/13 23:52, Crist Clark wrote:

 I've just set up an RPZ using a third party feed. I am getting lots and
 lots of info and warning messages in the logs. However, I am not
 sure whether they actually are indicative of a problem I that may be
 impacting operations or just a nice to know about something over which
 I have no control anyway (like lame server whining).


 What version of bind / RPZ patchlevel are you running, and what's your
 exact RPZ config?

 Does the server look busier to an unusual degree since you enabled RPZ?

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

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

RPZ Errors

[Crist Clark]

I've just set up an RPZ using a third party feed. I am getting lots and
lots of info and warning messages in the logs. However, I am not sure
whether they actually are indicative of a problem I that may be impacting
operations or just a nice to know about something over which I have no
control anyway (like lame server whining).

I see several types of messages, time outs,

2013-11-08 15:06:53 PST,daemon,WARNING,named[32015],client
172.26.216.139#58010 (ads1.msads.net): rpz NSIP rewrite
2-04-0073-0006.cdx.hwcdnlb.net via cdx.hwcdnlb.net NS db_find() failed:
timed out

And duplicate queries,

2013-11-08 15:06:50 PST,daemon,INFO,named[32015],client
172.26.216.139#58010 (ads1.msads.net): rpz NSIP rewrite
2-04-0073-0006.cdx.hwcdnlb.net via cdx.hwcdnlb.net unrecognized NS
db_find() failed: duplicate query

And a generic failed failure,

2013-11-08 15:06:34 PST,daemon,WARNING,named[32015],client
10.10.10.215#4390 (
0.0.295.0.0.3.0.0.59.aa.2b.0.0.0.60.08.03.efbbd39f722e543fbb8d70c34c27c90d6bcf8725fa7f13247036090d8761e70.f.08.s.sophosxl.net):
rpz NSIP rewrite
0.0.295.0.0.3.0.0.59.aa.2b.0.0.0.60.08.03.efbbd39f722e543fbb8d70c34c27c90d6bcf8725fa7f13247036090d8761e70.f.08.s.sophosxl.netvia
f.08.s.sophosxl.net NS db_find() failed: failure

And my favorite reason, which I won't bother to include a log entry since
they're all on internal zones other readers couldn't troubleshoot anyway,
glue.

I can't find any documentation of what these mean and if they are cause for
concern.

This is BIND 9.9.2 (Infoblox 6.7.3).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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