Re: Changing DNS servers (name only) for a DNSSEC enabled domain

2023-02-13 Thread 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: DNSSEC error resolving gpo.gov ?

2023-03-14 Thread 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: replace "SERVFAIL" to "NXDOMAIN" with rpz

2023-06-16 Thread 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: What is the equivalent of this dnsmasq configuration

2023-06-18 Thread 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: sub-subdomian not being resolved NXDOMAIN.

2023-12-02 Thread 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: Value of a DNSSEC validating resolver

2023-12-02 Thread 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: Remove PDF-related bits from the build system

2023-12-21 Thread 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


Some Authoritative-Only BCPs

2024-03-27 Thread 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: Some Authoritative-Only BCPs

2024-03-31 Thread 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


Broken DNS QNAME Recovery

2024-04-18 Thread 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


RPZ Errors

2013-11-08 Thread 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

Re: RPZ Errors

2013-11-11 Thread 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 wrote:

> 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

Re: RPZ Errors

2013-11-13 Thread 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  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


RPZ Still Doing Recursive Lookups

2015-02-24 Thread 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: TXT with dot in NAME for ACME via dynamic update

2020-03-14 Thread 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


Re: DNSSEC migration sanity check

2020-08-19 Thread 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: [RESOLVED] Re: No response from localhost with "allow-query { any; };"

2020-09-04 Thread 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&bind
> 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: Authority and forwarding, but not recursion/iteration

2021-03-06 Thread 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: Authority and forwarding, but not recursion/iteration

2021-03-07 Thread 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

2021-03-07 Thread 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: forwarding zone setup from a BIND slave (without recursion?)

2021-04-18 Thread 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: Recursion setting for bind9

2021-09-29 Thread 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: ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet

2021-12-10 Thread 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: ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet

2021-12-11 Thread Crist Clark
r.arpa.
>
> @   IN  NS  domac.alu.hr.
> @   IN  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 fo

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

2021-12-12 Thread Crist Clark
explanation. It was much 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?

Re: Forwarding zone, setup

2022-02-28 Thread 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: Communication error when we do axfr query for the large size zone

2022-04-19 Thread 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


dnstap to Splunk

2022-05-20 Thread 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: BIND9 TSIG from Windows Server 2016 DNS Server Zone

2022-05-25 Thread 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


Re: resolving www.ecb.europa.eu tages ages

2022-06-17 Thread 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
> F/+D

Re: Can't modify an existing SPF record

2022-07-08 Thread 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: Installing bind on Windows 10

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

2022-09-29 Thread 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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-22 Thread 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: [KASP] setup KASP in master / slave architecture

2022-12-16 Thread 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: how to dynamically change/update (own private) domain record

2018-09-23 Thread 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


Re: 2 Questions - forward zone and DNS firewalling

2018-10-25 Thread 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: EDNS Compliance

2019-01-18 Thread 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:

2019-02-19 Thread 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: BIND 9.11.5-P4 can't do ipv6 recursion

2019-03-18 Thread 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: RPZ and forward zone trouble

2019-03-25 Thread 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 M

Re: DDNS with extra vhosts...

2019-09-29 Thread 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


BIND Workaround for Broken DNS

2020-01-17 Thread 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: Referencing by cname from one authoritative zone to another authoritative zone

2024-10-03 Thread Crist Clark
If you want it to chase down the CNAME target data from another zone,
you're asking for recursion, not authoritative-only, so those results make
perfect sense.

Think of it this way. The fact both zones happen to be served by the same
name server is irrelevant. You should get the same authoritative answer if
the zones are different servers or the same servers.

On Thu, Oct 3, 2024 at 5:44 PM 大浦 義  wrote:

> Are searches from one authoritative zone to another authoritative zone
> using cname no longer allowed?
>
> /etc/named.conf
> acl "local" {
> xxx.xxx.xxx.xxx; 127.0.0.1;
> };
> ・
> ・
> ・
> allow-recursion { local; };
>
> --
> Client xxx.xxx.xxx.xxx→9.9.4:OK 9.9.18:OK
> Client yyy.yyy.yyy.yyy(not include acl) →9.9.4:OK 9.9.18:NG
>
>
> -Original Message-
> From: 大浦 義
> Sent: Friday, October 4, 2024 9:35 AM
> To: Matus UHLAR - fantomas ; bind-users@lists.isc.org
> Subject: RE: Referencing by cname from one authoritative zone to another
> authoritative zone
>
> Dear.
>
> ・9.9.4
> Master
> ns0.bbb.co.jp
> Slave
> ns1.bbb.co.jp
> ns2.bbb.co.jp
>
> ・9.18.28
> Master
> ns0-2024.bbb.co.jp
> Slave
> ns1-2024.bbb.co.jp
> ns2-2024.bbb.co.jp
>
> # dig @ns1-2024.bbb.co.jp ns2.bbb.co.jp.
>
> ; <<>> DiG 9.18.28 <<>> @ns1-2024.bbb.co.jp ns2.bbb.co.jp.
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12653 ;; flags: qr aa
> rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion
> requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 86a5aef292eec670010066ff3765baf0fbd3340da90b (good) ;;
> QUESTION SECTION:
> ;ns2.bbb.co.jp.  IN  A
>
> ;; ANSWER SECTION:
> ns2.bbb.co.jp.   900 IN  A   1.2.3.5
>
> ;; Query time: 6 msec
> ;; SERVER: 1.2.3.14#53(ns1-2024.bbb.co.jp) (UDP) ;; WHEN: Fri Oct 04
> 09:31:33 JST 2024 ;; MSG SIZE  rcvd: 89
>
>
>
> -Original Message-
> From: bind-users  On Behalf Of Matus
> UHLAR - fantomas
> Sent: Thursday, October 3, 2024 6:50 PM
> To: bind-users@lists.isc.org
> Subject: Re: Referencing by cname from one authoritative zone to another
> authoritative zone
>
> On 03.10.24 09:21, 大浦 義 wrote:
> >・9.9.4→OK
> ># dig @ns1.bbb.co.jp time1.aaa.ne.jp
>
> >;; ANSWER SECTION:
> >time1.aaa.ne.jp.   3600IN  CNAME   ns2.bbb.co.jp.
> >ns2.bbb.co.jp.   900 IN  A   1.2.3.5
> >
> >;; AUTHORITY SECTION:
> >bbb.co.jp.   900 IN  NS  ns6-tk02.ccc.ad.jp.
> >bbb.co.jp.   900 IN  NS  ns2.bbb.co.jp.
> >bbb.co.jp.   900 IN  NS  ns1.bbb.co.jp.
> >
> >;; ADDITIONAL SECTION:
> >ns1.bbb.co.jp.   900 IN  A   1.2.3.4
>
> >・9.18.28→NG
> ># dig @ns1-2024.bbb.co.jp time1.aaa.ne.jp
>
> >;; ANSWER SECTION:
> >time1.aaa.ne.jp.   3600IN  CNAME   ns2.bbb.co.jp.
>
>
> Now do:
> dig @ns1-2024.bbb.co.jp ns2.bbb.co.jp.
>
> what records does ns2.bbb.co.jp. have on ns1-2024.bbb.co.jp ?
>
>
> >On 03.10.24 08:40, 大浦 義 wrote:
> >>Referencing by cname from one authoritative zone to another
> authoritative zone may not work properly depending on the version.
> >>Is this due to a specification change? Is there a way to handle this?
> >>I am running nslookup from a client that is not included in acl
> respectively.
> >>I would like to make the NG part become OK.
> >>
> >>--
> >>One Server Has Two Zone.
> >>aaa.ne.jp & bbb.co.jp
> >>
> >>・aaa.ne.jp
> >>time1 CNAME   ns2.bbb.co.jp.
> >>time2 CNAME   ns1.bbb.co.jp.
> >>
> >>・bbb.co.jp
> >>ns1   A   1.2.3.4
> >>ns2   A   1.2.3.5
> >>time  CNAME   ns2
> >>
> >>・Bind9.9.4→OK
> >>>nslookup time2.aaa.ne.jp
> >>名前:ns1.bbb.co.jp
> >>Address:  1.2.3.4
> >>Aliases:  time2.aaa.ne.jp
> >>
> >>・Bind9.18.28→NG
> >>>nslookup time2.aaa.ne.jp
> >>名前:ns1.bbb.co.jp
> >
> >nslookup is NOT a good tool to resolve DNS problems.  Use "dig" instead.
> >
> >
> >dig time2.aaa.ne.jp @"IP of Bind9.9.4"
> >
> >
> >dig time2.aaa.ne.jp @"IP of Bind9.18.28"
>
> --
> 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.
> How does cat play with mouse? cat /dev/mouse
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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-u

Re: Question about DNSSEC

2024-10-31 Thread Crist Clark
Name names. DNS is out there in public.

There are a LOT of US .gov sites where the .gov is all signed, but it ends
up in $BIGCLOUDPROVIDER that is not.

www.gsa.gov
www.state.gov
www.house.gov
www.senate.gov
www.cia.gov
www.cisa.gov (*ehem*)
www.get.gov (not even .gov is signed?!)

Same thing for a lot of .mil.

On Thu, Oct 31, 2024 at 3:34 PM Mark Andrews  wrote:

>
>
> > On 1 Nov 2024, at 09:15, Bob McDonald  wrote:
> >
> > If a host is defined as a CNAME chain where the domain of the host is
> DNSSEC signed but the domain(S) of the target(s) in the CNAME chain are
> not, does that mean that the entry really isn't DNSSEC protected?
>
> Correct.  Every element of the chain needs to be DNSSEC signed (and
> validated as secure) for it to be protected.
>
> > I can list an example dig for the host in question but I'm reluctant to
> do so as it's a US gov host.
> >
> > Please advise.
> >
> > Regards,
> >
> > Bob
> > --
> > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
> >
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> 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: Problems with the Deletion of Retired Keys in DNSSEC

2024-11-07 Thread Crist Clark
You need to tell BIND the DS is gone from the parent. See the usage for,

rndc dnssec -checkds withdrawn 

On Thu, Nov 7, 2024 at 12:04 PM Τάσος Λολότσης  wrote:

> Hello all,
>
>  I’m currently facing an issue with DNSSEC key management in BIND and
> would appreciate any insights or experiences you might have.
>
> I have configured a DNSSEC policy for my domain with the following
> settings:
>
> keys {
> csk key-directory lifetime P365D algorithm ecdsa256;
> };
>
> // Key timings
> dnskey-ttl PT1H;
> publish-safety PT1H;
> retire-safety PT1H;
> purge-keys P30D;
>
> // Signature timings
> signatures-refresh P5D;
> signatures-validity P14D;
> signatures-validity-dnskey P14D;
>
> // Zone parameters
> max-zone-ttl P1D;
> zone-propagation-delay PT5M;
> parent-ds-ttl P1D;
> parent-propagation-delay PT1H;
>
> After running the command dnssec -status, I see the following key status
> for
>
> Key ID: 1002 (ECDSAP256SHA256):
>
> Published: Yes - since Wed Oct 4 14:01:53 2023
> Key Signing: Yes - since Wed Oct 4 14:01:53 2023
> Zone Signing: No
> Key is Retired: Will be removed on Sun Oct 13 15:06:53 2024
>
> Goal: Hidden
> DNSKEY: Omnipresent
> DS: Unretentive
> Zone RRSIG: Hidden
> Key RRSIG: Omnipresent
>
> Also this is the details status of the Key
>
> Algorithm: 13
> Length: 256
> Lifetime: 31536000
> Successor: 39133
> KSK: yes
> ZSK: yes
> Generated: 20231004120153 (Wed Oct 4 14:01:53 2023)
> Published: 20231004120153 (Wed Oct 4 14:01:53 2023)
> Active: 20231004120153 (Wed Oct 4 14:01:53 2023)
> Retired: 20241003120153 (Thu Oct 3 14:01:53 2024)
> Removed: 20241013130653 (Sun Oct 13 15:06:53 2024)
> DSPublish: 20231120105349 (Mon Nov 20 11:53:49 2023)
> PublishCDS: 20231005130653 (Thu Oct 5 15:06:53 2023)
> DNSKEYChange: 20231004140653 (Wed Oct 4 16:06:53 2023)
> ZRRSIGChange: 20241013130653 (Sun Oct 13 15:06:53 2024)
> KRRSIGChange: 20231004140653 (Wed Oct 4 16:06:53 2023)
> DSChange: 20241003120153 (Thu Oct 3 14:01:53 2024)
> DNSKEYState: omnipresent
> ZRRSIGState: hidden
> KRRSIGState: omnipresent
> DSState: unretentive
> GoalState: hidden
> I am using the DNSSEC policy settings as shown above, but it appears that
> BIND is not automatically removing the key as expected.
>
> The key still seems to be in use, and it has not been removed from the
> system despite reaching its retirement and removal dates.
>
> Has anyone else experienced similar issues with DNSSEC policies in BIND?
>
> If so, how did you resolve it? Any advice on troubleshooting or correcting
> this issue would be greatly appreciated.
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Undelegating a Signed Subdomain

2024-12-09 Thread Crist Clark
We have a zone, "bar.example.com," that is all properly delegated from "
example.com." Although the subzone still has many records, "
foo.bar.example.com" and such, the administrative reasons for having it as
a separate zone are not so important anymore, and it would be convenient to
simply manage it as multi-label names all within the example.com zone. That
is, foo.bar.example.com would now just be in example.com.

The first thing that ups the degree of difficulty is DNSSEC. example.com is
signed. bar.example.com is properly delegated and also signed. How do we
make the transition without invalidating bar.example.com and its contents?
I can't think of a way to transition bar.example.com without going
insecure, letting that propagate out, and then folding bar.example.com into
example.com. Or is there some way we could do it without going insecure
first?

I am also a little concerned about pre-loading the multi-label names at
bar.example.com and above into example.com. example.com and bar.example.com
have the same NS records, the same servers. Could it present any issues
having those "hidden" records and their associated NSEC3 records in
example.com while the server still is serving bar.example.com? Would we
want to go insecure with example.com too, just to be safe?

Even without DNSSEC, there are some problems. If we manage an
instantaneous change on all of the authoritative servers at once, we can
still have cached records out there. You could still have a resolver with
the NS and SOA of bar.example.com cached. It goes to ask for "
doesntexist.bar.example.com" and gets a NXDOMAIN with an SOA for example.com
in the auth section. It's expecting the SOA for bar.example.com. A
standard-compliant resolver won't accept that.

Am I just over-thinking this? Just lower the TTLs on the NS and DS records
for bar.example.com as far as we dare, and make the changes and hope for
the fewest inconsistencies possible? Are there some steps to take to do
this with minimal chances for inconsistencies and breakage?

We're using BIND dnssec-policy to manage DNSSEC for the zones.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: shut down hung fetch while resolving 'aro.army.mil.edgekey.dmz.akamai.csd.disa.mil/A'

2024-12-17 Thread Crist Clark
This is the problem:

https://lists.isc.org/mailman/htdig/bind-users/2024-April/108469.html

Not a new problem.

https://lists.isc.org/mailman/htdig/bind-users/2018-May/100229.html


On Tue, Dec 17, 2024 at 12:19 PM Ondřej Surý  wrote:

> Crosscheck this with DNSSEC Debugger from Verisign:
>
> dnssec-analyzer.verisignlabs.com
> 
> 
> 
>
>
> [image: red.png] No DS records found for akamai.csd.disa.mil in the
> csd.disa.mil zone
> [image: yellow.png] All Queries to dns3.akamai.csd.disa.mil for
> akamai.csd.disa.mil/DNSKEY timed out or failed
> [image: yellow.png] All Queries to dns1.akamai.csd.disa.mil for
> akamai.csd.disa.mil/DNSKEY timed out or failed
> [image: yellow.png] All Queries to dns2.akamai.csd.disa.mil for
> akamai.csd.disa.mil/DNSKEY timed out or failed
> [image: yellow.png] All Queries to dns4.akamai.csd.disa.mil for
> akamai.csd.disa.mil/DNSKEY timed out or failed
> [image: red.png] Failed to get DNSKEY RR set for zone akamai.csd.disa.mil
> [image: yellow.png] All Queries to dns2.akamai.csd.disa.mil for
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil/A timed out or failed
> [image: yellow.png] All Queries to dns4.akamai.csd.disa.mil for
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil/A timed out or failed
> [image: yellow.png] All Queries to dns3.akamai.csd.disa.mil for
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil/A timed out or failed
> [image: yellow.png] All Queries to dns1.akamai.csd.disa.mil for
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil/A timed out or failed
> [image: red.png] No response from akamai.csd.disa.mil nameservers
>
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> On 17. 12. 2024, at 21:16, Ondřej Surý  wrote:
>
> disa.mil servers are timing out on me over IPv6:
>
> $ dig IN NS gcds.disa.mil. @DNS1.DISA.MIL.
> ;; communications error to 2608:125:0:1811:1001:9012:f00:20#53: timed out
> ;; communications error to 2608:125:0:1811:1001:9012:f00:20#53: timed out
> ;; communications error to 2608:125:0:1811:1001:9012:f00:20#53: timed out
>
> ; <<>> DiG 9.21.3-1+0~20241211.133+debian12~1.gbp5b5fe5-Debian <<>> IN NS
> gcds.disa.mil. @DNS1.DISA.MIL.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55426
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 7
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;gcds.disa.mil. IN  NS
>
> ;; ANSWER SECTION:
> gcds.disa.mil.  12699   IN  NS  dns1.disa.mil.
> gcds.disa.mil.  12699   IN  NS  dns3.disa.mil.
> gcds.disa.mil.  12699   IN  NS  dns5.disa.mil.
> gcds.disa.mil.  12699   IN  NS  dns2.disa.mil.
> gcds.disa.mil.  12699   IN  NS  dns4.disa.mil.
>
> ;; ADDITIONAL SECTION:
> dns1.disa.mil.  7151IN  
>  2608:125:0:1811:1001:9012:f00:20
> dns2.disa.mil.  7151IN  
>  2608:102:0:182d:1001:9012:c00:20
> dns3.disa.mil.  7151IN  
>  2608:145:0:180b:1001:9012:d00:20
> dns4.disa.mil.  6608IN  
>  2608:c182:0:1012:1001:9012:1400:20
> dns4.disa.mil.  6608IN  
>  2608:c182::1001:9012:1600:20
> dns5.disa.mil.  7151IN  
>  2608:4122:0:1012:1001:9012:1400:20
>
> ;; Query time: 252 msec
> ;; SERVER: 152.229.110.232#53(DNS1.DISA.MIL.) (UDP)
> ;; WHEN: Tue Dec 17 21:09:53 CET 2024
> ;; MSG SIZE  rcvd: 305
>
> And given there's so many delegations and so many redirections, the result
> is inevitable...
>
> There's at least 4 queries that need to be done against disa.mil servers
> and if they all end up with timeout over IPv6, the whole query times out
> because it will run out of the time.
>
> gdcs.disa.mil IN NS
> apps.gdcs.disa.mil IN NS
> cds.disa.mil IN NS
> e1008.d.akamaiedge.akamai.csd.disa.mil. IN A
>
> Ondřej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> On 17. 12. 2024, at 20:56, Clark, Roger  wrote:
>
> I have a user who is unsuccessfully trying to resolve ‘
> extranet.aro.army.mil’ using our BIND resolvers.  The query is failing
> with a 'shut down hung fetch while resolving’ error message with some
> DNSSEC warning as well.  The name resolves without issue querying other
> external resolvers and also is successful using dig +trace.  I did notice
> there was an issue with an error produced by one of the names in the CNAMe
> chain ( https://gitlab.isc.org/isc-projects/bind9/-/issues/4797 ).
>
> Do I have something 

Re: Executive Order 14144 - encrypted DNS

2025-01-27 Thread Crist Clark
US Federal civilian agencies have been required to do DNSSEC validation for
over ten years.

On Mon, Jan 27, 2025 at 7:42 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

> On 1/27/25 07:02, Carlos Horowicz via bind-users wrote:
> > IMHO this has nothing to do with DNSSEC,
>
> HEAVYsigh
>
> Why do things seem to focus on the encryption of DNS traffic and ignore
> authentication of the information?
>
> I'm sure that all of us are aware that it's perfectly possible for a DoT
> / DoH server to send bogus information through the encryption.
>
> In some ways, advocating for encryption without authentication is akin
> to advocating for self-signed TLS certificates for web-sites.  Anybody
> can monkey in the middle the traffic if they want to.
>
> I've not read any of the cited articles yet, but I assume DNS w/ DNSSEC
> through VPN isn't mentioned.
>
>
>
> --
> Grant. . . .
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: DNSVIZ errors

2025-04-20 Thread Crist Clark
The version of BIND and where you got it would be a good start. Any load
balancers, firewalls, etc. between the server and internet that might touch
the DNS records?

True DNSSEC gurus please check my math.

DNSvis is correct. You're not sending the proper NSEC3 records. Like the
RFC says, "It takes three to tango," or NSEC3 denial of existence. You sent
two. For a name where two levels of label don't exists,

l5tz4.1i89a.akritrim.net

You should send back three NSEC3 records,

1) NSEC3 record that proves 1i89a.akritrim.net (
18QMAAOCT0HPNGCPD9MLONVAK13DS8HT) does not exist.
2) NSEC3 record for akritrim.net (N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P).
3) NSEC3 record proving the wildcard, *.akritrim.net (
6L23GRBE4JIMA1A0G8DSBBUT32V6VCO1), does not exist.

But you're not, you're only sending two,

N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P.akritrim.net. 600 IN NSEC3 1 0 0 -
QDO3A5R9G64L616H1K2FF3SUMFPPRV3J A NS SOA MX TXT  RRSIG DNSKEY
NSEC3PARAM CDS CDNSKEY CAA

67QJN06FLKRQCT38S4FF08EP31NDRL8S.akritrim.net. 600 IN NSEC3 1 0 0 -
6LPNNJIVL1267OV5QQSBFLMFIDHMHJ8P TXT RRSIG

Those are two I'd expect to see for (2) and (3), but where is (1)?

But it's weirder. For this name,

ebzoq.ik7ub.akritrim.net

You are sending three NSEC3, but one doesn't look like the right one. You
should send,

1) NSEC3 record that proves 1i89a.akritrim.net (
S2NOKIAA732BLNNSEMCJ8KV74H6ICUEP) does not exist.
2) NSEC3 record for akritrim.net (N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P).
3) NSEC3 record proving the wildcard, *.akritrim.net (
6L23GRBE4JIMA1A0G8DSBBUT32V6VCO1), does not exist.

But these get sent,

N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P.akritrim.net. 600 IN NSEC3 1 0 0 -
QDO3A5R9G64L616H1K2FF3SUMFPPRV3J A NS SOA MX TXT  RRSIG DNSKEY
NSEC3PARAM CDS CDNSKEY CAA

I559SEFHCJO35HED2LU4N68B44CA281V.akritrim.net. 600 IN NSEC3 1 0 0 -
KOGD0HOUD9R7BAB4LKQR2E9ALI57C7N0 A  RRSIG CAA

67QJN06FLKRQCT38S4FF08EP31NDRL8S.akritrim.net. 600 IN NSEC3 1 0 0 -
6LPNNJIVL1267OV5QQSBFLMFIDHMHJ8P TXT RRSIG

The first and last are the same two we got previously and line up with (2)
and (3). But we get this other one that doesn't line up with (1). But what
I /think/ that might be is the record that would prove
ebzoq.ik7ub.akritrim.net (IAT39F3MSSGS2D4O255VNHB67V2GCNVI) does not exist
in its place.

On Sun, Apr 20, 2025 at 10:29 AM akritrim® Intelligence™ via bind-users <
bind-users@lists.isc.org> wrote:

> i didn't specifically ask for your help. i don't know why you replied. yes
> i do need help but this doesn't mean i can read your mind.
>
> so let me know what 'bits' of information should i share that will
> meaningfully help me. ( this is equivalent to saying '
> if you need anything specific let me know.')
>
> today language models are more context aware.
>
> and if you don't want to share what do you 'need' then leave it be, i
> don't want your help.
>
>
> On April 20, 2025 5:17:46 PM UTC, "Ondřej Surý"  wrote:
> >
> >> On 20. 4. 2025, at 17:57, akritrim® Intelligence™ via bind-users <
> bind-users@lists.isc.org> wrote:
> >>
> >> anyways, if you need anything specific let me know.
> >
> >Well, I don't really need anything, you've asked for help here, not I.
> I've already told you what is needed,
> >you didn't follow my advice :shrug:. The bits of information you have
> provided are not sufficient to meaningfully
> >help you.
> >
> >Ondrej
> >--
> >Ondřej Surý (He/Him)
> >ond...@isc.org
> >
> >My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
> >
> >
>
> akritrim® Intelligence™
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: xfer-in: Transfer status: timed out (selective failures)

2025-02-24 Thread Crist Clark
Another thing to consider, especially if you are playing wild games routing
through tunnels and such, is to verify the server has a route back to the
client. If something in the LAN can reach it, like the first dump, but
off-net gets no response, like the second, that’s a classic cause.

On Mon, Feb 24, 2025 at 4:19 PM Timothe Litt via bind-users <
bind-users@lists.isc.org> wrote:

> On 24-Feb-25 17:54, Peter 'PMc' Much wrote:
>
> tcpdump was friendly enough to tell me I should use -vv option,
> only I didn't read that at first.
> Then it clearly shows that these packets have invalid checksums. :(
>
> And that is apparently reason enough to just drop them without
> notice.
>
> Now how they aquire broken checksums, and why they start to
> do so two days ago (because I find some successful XFR in the log,
> until Feb-22), that is another story.
>
> A couple of hints:
>
> The bad checksums may be a false lead.  If you have a network interface
> that off-loads checksum computation, the checksum (valid or invalid) may
> not appear in the user/trace buffer.  (Depends on the interface & driver.)
>
> If your NAT is changing IP addresses, it may not recompute the checksum
> (for the same reason - you can't count on it being valid in the buffer).
>
> You can mark packets with IPtables to make tracking/logging easier.
>
>
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: My Introduction and current issues -

2025-05-09 Thread Crist Clark
If you’re hobbled by Windows (and ones five years past EOL), I prefer to
fire up PowerShell and use Resolve-DnsName. Also include the -DnsOnly flag.

Have you been looking at the BIND logs?

Also, a BIND installation isn’t going to mess with resolv.conf. That’s
typically managed by the distro’s network configuration management tool,
e.g. NetworkManager.

On Fri, May 9, 2025 at 8:30 PM  wrote:

> >I also suspect it's not BIND, but how the OS is going about resolving
> names.
> >Test your running BIND by using dig (please, not nslookup) @127.0.0.1
> for domains you think you are having a problem with.
>
> *Should it be @127.0.0.1  or should it be the machine's
> IP on which the DNS server is running?*
>
> >Also check /etc/resolv.conf and see what address(es) is/are listed as
> nameservers.
>
> *The resolv.conf file contains:*
>
> *  nameserver 127.0.0.53*
>
> *  search mydomain.net    (where mydomain is my
> actual domain name and not the FQDN of the machine (i.e.
> "machine01.mydomain.net ")).   *
>
> *This was entered by default as BIND was installed.   I am wondering if
> the "namesever" should be the machine name on which the server is running
> and not 127.0.0.53 And I gather the 53 on the end has to do with the port
> on which it's listening. I'm not sure if it's correct that the 4th octet is
> substituted like that. *
>
> >Third, use tcpdump to capture port 53. Do this to a file, then look at it
> offline in Wireshark. (Michael just beat me to that tip). Check how queries
> are arriving into BIND and what it does >with them. Particularly look at
> the timings of packets and for errors, such as packet loss or ICMP.
>
> *I will look into this. I need to learn a little more about tcpdump.   I
> don't have Wireshark but I'll make do.*
>
> >A couple of comments about your BIND config:
> >1) You don't need "zone "." as root hints have been built into BIND for
> many years. If you are global forwarding (also "forward only") then
> recursion will never happen, so roots are >irrelevant.
>
> *OK.*
>
> >2) BIND will recurse just fine out of the box. You don't need to forward
> to Google and Cloudflare at all.
>
> *So, should I remove the "forwarders" entry?  At which resolver server,
> then, would it begin the forwarding process?*
>
>
>
> On 2025-05-09 18:35, Greg Choules wrote:
>
> Hi.
> I also suspect it's not BIND, but how the OS is going about resolving
> names.
> Test your running BIND by using dig (please, not nslookup) @127.0.0.1 for
> domains you think you are having a problem with.
>
> Also check /etc/resolv.conf and see what address(es) is/are listed as
> nameservers.
>
> Third, use tcpdump to capture port 53. Do this to a file, then look at it
> offline in Wireshark. (Michael just beat me to that tip). Check how queries
> are arriving into BIND and what it does with them. Particularly look at the
> timings of packets and for errors, such as packet loss or ICMP.
>
> A couple of comments about your BIND config:
> 1) You don't need "zone "." as root hints have been built into BIND for
> many years. If you are global forwarding (also "forward only") then
> recursion will never happen, so roots are irrelevant.
> 2) BIND will recurse just fine out of the box. You don't need to forward
> to Google and Cloudflare at all.
>
> Hope you find that useful.
> Cheers, Greg
>
> On Fri, 9 May 2025 at 23:58,  wrote:
>
> Howdy all!.   My name is Arnold, and I'm new to both Bind9 and to the Bind
> user's list. I'm hoping to contribute my findings on the use of Bind9. in
> the future but, for now, I need some help in getting my 1st install of Bind
> 9.18 performing well. It does run already, but does not perform well at
> all. I'll explain.
>
>
> First, a quick bit of history. I run a home network (a full domain
> structure) and, for the past 23 years, I ran a server (Windows Server 2003)
> as a full Primary Domain Controller in my home network. I ran DHCP, DNS and
> AD on that server. It worked great and had extremely fast responses for DNS
> forwarding. Very rarely was there ever a failure (i.e. "Site not found" or
> "No Internet Access") etc. And it ran great for almost 23 years Until
> this past Easter Sunday, when it died a nasty hardware death. I deemed it
> unworthy of repairing. This because, 2 years ago, I began building two new
> mid-tower machines (Intel coreI7 and was going to install Ubuntu Server
> (22.04) on one and the 22.04 client on  the other. I completed the client
> machine and it is up and running perfectly. I held off on the server as my
> Win2003 server was still running. But not anymore.
>
> I resumed the build of the Ubuntu Server (22.04). I installed
> ISC-DHCP-Server for DHCP (I know Kea is available but I read where that
> needs Ubuntu 24.xx+). I also installed Bind9.18 as the DNS server. The DHCP
> server is working perfectly.  No issues at all. Very happy with it.  The
> Bind9.18, not so much.   BTW, I'll deal 

Migration to inline-signing

2025-05-16 Thread Crist Clark
Tired of looking at the log messages warning me that inline-signing will be
the default in 9.20. I want to convert my 9.18 to using inline-signing.
Right now all of the zones use dnssec-policy and are dynamic.

I tried just simply adding the "inlien-signing yes" line to a zone with
dynamic updates that has the DNSSEC records in the file, but it flat out
stopped the zone from loading at all when I issued a reconfig.

I assume I could freeze, sync, clean DNSSEC records in the file, and reload
with inline-signing. But manually cleaning the zone file isn't trivial. Not
hard, but takes some work to get right.

Is there a right way to just reconfigure named.conf to make this work
without messing with the zone file directly? Even if it maybe takes steps?

If this really takes cleaning the DNSSEC from the zone file, is there a way
to coax the existing BIND tools to do this? Took a quick look at
named-compilezone, dnssec-signzone, etc. None seem to have the capability.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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

2025-05-23 Thread Crist Clark
I tried it again to get the logs,

*21-May-2025 20:57*:12.064 general: zone sub.example.com/IN/internal:
(primary) removed

*21-May-2025 20:57*:12.064 general: reloading configuration succeeded

*21-May-2025 20:57*:12.064 general: scheduled loading new zones

*21-May-2025 20:57*:12.511 zoneload: zone sub.example.com/IN/internal
(unsigned):
loaded serial 462767 (DNSSEC signed)

*21-May-2025 20:57*:12.600 general: zone sub.example.com/IN/internal (signed):
CDS/CDNSKEY consistency checks failed

*21-May-2025 20:57*:12.600 zoneload: zone sub.example.com/IN/internal (signed):
not loaded due to errors.

*21-May-2025 20:57*:12.600 general: zone sub.example.com/IN/internal (signed):
receive_secure_db: bad CDS

I wanted to reduce it to a minimum configuration to reproduce and present
that, but I also was working on the approach of purging the zone file of
DNSSEC records. Didn't have time to do both. Removing the records wasn't as
bad as I thought, simple awk script seems to work,

{

   sub(/;.*/,"")

}

/\s(DNSKEY|CDNSKEY|DS|CDS|RRSIG|NSEC|TYPE65534)/ {

   if (/\(/) {

  while (!(/\)/)) {

 getline

  }

   }

   next

}

{

   print

}

Although I can imagine some cases where that logic is too simple.

Purging the records and then loading the zone worked, but still wasn't as
smooth as I liked, I tried,

1. freeze
2. sync -clean
3. Copy the de-DNSSECed fzone file over the old one
4. thaw

But that would write the zone back with DNSSEC records in the file. The
only way I got it to work was to kill and restart named.

Given the actual primary is a hidden master, brief named outages for a
restart are not a big concern. That's probably good enough.


On Tue, May 20, 2025 at 1:45 AM Matthijs Mekking  wrote:

>
>
> On 17-05-2025 06:39, Crist Clark wrote:
> > Tired of looking at the log messages warning me that inline-signing will
> > be the default in 9.20. I want to convert my 9.18 to using
> > inline-signing. Right now all of the zones use dnssec-policy and are
> > dynamic.
> >
> > I tried just simply adding the "inlien-signing yes" line to a zone with
> > dynamic updates that has the DNSSEC records in the file, but it flat out
> > stopped the zone from loading at all when I issued a reconfig.
>
> Can you tell me the error message? I would not expect the zone stopping
> from loading, but it's hard to tell without full configuration.
>
> Note that when switching, signatures and NSEC records from the dynamic
> zone would be removed and moving to inline-signing requires a full
> re-sign of the zone.
>
> - Matthijs
>
> > I assume I could freeze, sync, clean DNSSEC records in the file, and
> > reload with inline-signing. But manually cleaning the zone file isn't
> > trivial. Not hard, but takes some work to get right.
> >
> > Is there a right way to just reconfigure named.conf to make this work
> > without messing with the zone file directly? Even if it maybe takes
> steps?
> >
> > If this really takes cleaning the DNSSEC from the zone file, is there a
> > way to coax the existing BIND tools to do this? Took a quick look at
> > named-compilezone, dnssec-signzone, etc. None seem to have the
> capability.
> >
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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: 127/8 weirdness & entertainment for fun & profit.

2025-07-08 Thread Crist Clark
Note that is all Linux-specific behavior. BSD-derived stacks are generally
different, e.g. FreeBSD and MacOS. They do not respond to addresses that
aren’t explicitly assigned to an interface. You cannot bind an address not
assigned to an interface.



On Sun, Jul 6, 2025 at 9:23 AM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

> New-Subject:  host vs subnet routes
> Old-Subject:  BIND doesn't listen to other loopback addresses
>
> On 7/6/25 1:02 AM, Ondřej Surý wrote:
> > The IPv4 loopback is actually quite weird in this regard that
> > 127.0.0.1/8 is assigned by everything in 127/8 automagically works
> > without explicit address assigned to the interface.
>
> This is a kernel default.  But you can fairly easily change this
> behavior for any interface / subnet you want to.
>
> The 127/8 that you mention is actually assigned as a route in the local
> routing table.
>
> % ip -4 route show table local | grep 127
> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
> local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
> broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
>
> It's specifically the `local 127.0.0.0/8` 
> route that is causing the
> behavior that you're describing.
>
> N.B. It is the route type of "local" that causes this behavior.  "local"
> routes tell the kernel that everything that matches the route is
> destined to the local system.  It just happens to be that said local
> route is located in the routing table named local.  But local route can
> go in other routing tables.
>
> You can change / remove that route to alter the behavior.
>
> More interestingly, you can add similar routes for other subnets /
> interfaces if you would like the same behavior for other things.  I've
> got the following on a router to cause it to act like 127/8 but for
> 192.0.2/8:
>
> % ip -4 route show table local | grep 192.0.2.
> local 192.0.2.0/24 dev eth1 scope host metric 4
> local 192.0.2.1 dev eth1 proto kernel scope host src 192.0.2.1
> broadcast 192.0.2.255 dev eth1 proto kernel scope link src 192.0.2.1
>
> Here are the related routes in the main routing table:
>
> % ip route show table main | grep 192.0.2.
> 192.0.2.0/24 dev eth1 proto kernel scope link src 192.0.2.1
> 192.0.2.7 dev eth1 scope link metric 4
> 192.0.2.24 dev eth1 scope link metric 4
>
> The 192.0.2.0/24 route in the main routing table is what is expected for
> a locally attached subnet.
>
> The 192.0.2.7 and 192.0.2.24 host routes in the main routing table are
> used to be a more specific match to override the less specific local
> 192.0.2.0/24 route in the local routing table.
>
> The net result is that the system thinks that all IPs in the
> 192.0.2.0/24 subnet are local to it with the two exceptions being
> 192.0.2.7 and 192.0.2.24.
>
> This also works for the systems in the subnet, when they ARP for any IP
> other than 192.0.2.7 or 192.0.2.24, the router replies to the ARP
> request, thereby causing all other 192.0.2.0/24 traffic to go to it.
>
> Yes, 127/8 is weird.  But it makes sense if you look at the routing
> tables.  It's also fun to apply the same behavior to other subnets /
> interfaces.  }:-)
>
>
>
> --
> Grant. . . .
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: question about resolving of AAAA amazoses.com

2025-07-05 Thread Crist Clark
Another operational impact of these broken servers, broken DNS64. BIND
wants to verify no  records exist for a QNAME before synthesizing
records, but since it can’t get a valid denial of existence, it won’t
return synthesized s.


On Sat, Jul 5, 2025 at 6:44 AM Bagas Sanjaya  wrote:

> On 7/5/25 19:17, Jeff Sumner wrote:
> > Apologies for the lack of clarity.
> >
> > We performed a major F5 upgrade recently – for which we were delegating
> > some zones from our ISC BIND servers (just Plain Old NS record
> > delegation) and ever since then, clients using nslookup and host, which
> > query the BIND servers (the recursers) are getting back both the correct
> > A records as well as two SERVFAILS as the  and MX record queries
> > error out (both nslookup and host query those record types in addition
> > to the A record query)– both of which cause the log emissions that we
> > see in this string. Can see the F5s handing back incorrect data in the
> > sniffer – so the BIND servers are acting correctly – the F5s are not.
> > We’re working that through.
> >
>
> OK, thanks!
>
> --
> An old man doll... just what I always wanted! - Clara
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://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