Re: Question about "too many records"

[Tim Daneliuk]

On 8/1/24 17:14, John Thurston wrote:

After reading the CVE description, it isn't clear to me how the degraded 
performance is manifest.

If 300 A-records exist for the name 'foo', do we expect:

 1. queries for A-records for 'foo' will be slower than expected
 2. all queries for 'foo' will be slower than expected
 3. every query to the server will be slower than expected
 4. something else




I also have a basic confusion about this general topic.

I got bit by this when I updated to .28 because I had some fairly
large round robin pools within our non-routable network.

In my (admittedly brief) research, I was under the impression that
the limitation was total number of records per type to reduce
the risk of cache poisoning, not for performance reasons.

If that's so, there needs to be a way to disable it by policy/option
for the local horizon in a split horizon implementation where one
might need a lot of records and the risk of cache poisoning is
essentially zero.

If someone would please help deconfuse me, I would be deeply appreciative.




--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska

On 8/1/2024 2:03 PM, James Stegemeyer wrote:

J,

This issue has been covered by earlier threads, and is mentioned on the
BIND 9.18.28 release notes.
Starting with BIND 9.18.28 changes were made to mitigate performance
impact CVE-2024-1737 BIND database will be slow if if a very large
number of RRs exist at the same name.

If you find yourself in this situation, you can increase the
"max-records-per-type" parameter which was introduced in bind 9.18.28.
I find that it is common for large Active Directory zone to have a large
quantity of RR with the same name which concentrates at the domain APEX
and for the LDAP SRV records. Increasing this parameter dilutes the
protection you will receive against CVE-2024-1737 the default value of
100 was chosen based on a performance knee which occurs at around 100
records.

You can use the following command, if you have access to a Linux based
system to create a histogram of number of RRs for the same name.

dig -t axfr $zone  @$server | awk '{print $1,$4}' | sort | uniq -c | sort -n


Thanks,
--James Stegemeyer

On 8/1/24 17:09, J Doe wrote:

Hi,

I run my own validating recursive resolver with BIND 9.18.28.

In the resolver logs I noticed:


    01-Aug-2024 10:30:22.294 query-errors: info: client @0xec879280280
    127.0.0.1#14435 (bf10x.hubspotemail.net): query failed (too many
    records) for bf10x.hubspotemail.net/IN/A at query.c:7842


The client in this case was my mail server software.  What does "query
failed (too many records) ..." mean ?

Is this BIND saying that the client (the mail server software),
requested too many records or that the result of the query yielded too
many records or something else ?

Thanks,

- J






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

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


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

Re: 9.18 horrendous

[Tim Daneliuk]

On 8/23/24 09:19, Marcus Kool wrote:

The user was angry and ranted about named 9.18.x.  He did not rant about any 
developer or any member of your team.  Removing a user from this list is IMHO 
not the best way to treat an issue.

Marcus





Yes, but tone matters.  It seems that world is now full people who deem 
themselves so
important that anything they say should be considered as absolutely truth and 
they
should be the center of attention.  These verbal bomb throwers make everyone 
around
them - both in real life and virtually - miserable.

What is almost always true about such people (I don't know in this case) is that
they do not contribute anything to help out.  They don't answer questions for
newer users, they contribute code, they don't contribute money ... nothing.

All they provide is complaints.  They love to bask in the glow of identifying
a problem.  That's it.

So if the list owner had enough, I think that just means the misery index was
exceeded.





On 23/08/2024 13:31, Ondřej Surý wrote:

I can understand your anger

But I don’t. Let me be absolutely clear. There’s nothing in the world that 
would allow you to treat me, my team and the other list members like this. And 
there’s nothing in the world that would justify such behavior.

The user in question has been removed from the list and banned. I would rather 
spent my energy on the users who treat other with respect than work around 
someone’s “anger”.

Ondřej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.


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

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


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

Best Practices: Slaves And Split Horizon Masters

[Tim Daneliuk]

I have a bind9 split horizon master with two views: internal and external.

However, if attempt to populate a slave from it, the internal view leaks out
and is visible to the world.

Is there some best practice for running slaves from split horizon masters
that I should be studying?

Thanks,
-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Best Practices: Slaves And Split Horizon Masters

[Tim Daneliuk]

On 08/21/2015 11:57 AM, Bob Harold wrote:
> https://kb.isc.org/article/AA-00296/0/My-slave-server-for-both-an-internal-and-an-external-view-has-both-views-transferred-from-the-same-master-view-how-to-resolve-.html
> 
> 
> 
> -- 
> Bob Harold
> hostmaster, UMnet, ITcom
> Information and Technology Services (ITS)
> rharo...@umich.edu <mailto:rharo...@umich.edu>
> 734-647-6524 desk
> 
>


Exactly what I needed, thanks!


-- 
--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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

More On Split Horizon & Slaves

[Tim Daneliuk]

I am still working through how to get this working but a little further
steering would be helpful.


I have a situation with a single domain "foo.com" That has both public
facing and NATed internal addresses.   That is, regardless of whether the
host IP is visible in the outside world or not, its canonical
name is, host.foo.com

Split horizon is set up on the master so that there is a database
for each view:

db.foo.external - Defines SOA, nameservers, public hosts, SPF, MX and
  so on for foo.com

db.foo.com.internal - This file begins with:

  $INCLUDE  master/db.foo.external

  Following this are all the host assignments
  for hosts on the non-routable (NATing)
  network.   


This works just fine and protects the internal namespace from the
public internet.


At the moment, there are two nameservers, each running as masters with
this configuration.   What I want to do is convert them to a master and 
slave instances, so only the master needs to be edited when changes are needed.

And ... that's where the wheels fall off.  The slave setup does work,
but no matter how I configure it, when a lookup takes place on the slave,
it leaks host assignments from the private view.  The relevant slave
configuration looks like this: 


view "internal" {
match-clients { trustedhosts; };
zone "foo.com"{ type slave; file "slave/db.foo.internal"; 
masters {1.2.3.4; }; };
zone "0.168.192.in-addr.arpa" { type slave; file "slave/db.192.168.0";
masters {1.2.3.4; }; };
};

view "external" {
match-clients { any; };
zone "foo.com" { type slave; file "slave/db.foo.external"; 
masters {1.2.3.4; }; };
};

My sense is that I need to split the internal and external host assignments on 
the master differently,
so that the slave knows which view is which, but I am not clear on how to do 
this when both views
are in the same namespace.

Any help would be appreciated ...

___
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: More On Split Horizon & Slaves

[Tim Daneliuk]

On 08/22/2015 10:42 AM, /dev/rob0 wrote:
> On Sat, Aug 22, 2015 at 09:53:31AM -0500, Tim Daneliuk wrote:
> [ Two views, one zone name, different zone contents,
>   same master & slave: how to populate both views on the slave? ]
> 
>> My sense is that I need to split the internal and external host 
>> assignments on the master differently, so that the slave knows 
>> which view is which, but I am not clear on how to do this when both 
>> views are in the same namespace.
> 
> https://kb.isc.org/article/AA-00296/0
> https://kb.isc.org/article/AA-00851/0
> 


Aha!  The magic trick (also suggested in private email) was the use
of keys to determine which database each view used.

Many thanks - all working nicely now.

-- 
--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Help DNS

[Tim Daneliuk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/23/2015 10:05 PM, Alan Clegg wrote:
> Never, EVER use nslookup.


Could you explain why?

- -- 
- ----
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV2qJ6AAoJEMLZ2alfelsnWrQP/2ECFXKjuUkK/ZMJUv0DNwAd
/K+TmGd1vpn4rLOFH063j8/fTnqzltFEXmUpx37MtUODa/BQl1rhppgdlfOrAIK5
FG1WTwVHy01g8ZXSUciPayACGW1MR+FX7d9bkmWh80GIX83RShH5YsEEkIIKsROB
oOdL3/o6oJCy/MIxlr27tfWC4phe11UMBGIWs0QFa2uvWozfDov5wn6+0iiLfnOu
Hn9fd7lT82GFMYJYSwgoTbxApzHAku32gm54Q3KQKhtBCGF0kg87G3sXXkRK7lpJ
EA/Ch0WrRmHsWw2C6PYGcZ0UnDrXs1+5cpLai7jrMs4TLahMS6495cvp9vylC3wS
N1ZqG8/GasPISvpLLlqLy5er6qEPXvaYL0K4KmQuT+v9M1ExeJcyfFMxPBbDI73k
zxaNJ633ER4H6HglQ3VtWB5oUw5aERCoBHm77VNbVEjei+6GzjHujoc6BTejHv5j
yKAg3wYw3SkKow2/nAmp4Of5FwtRqhYYwllvJQfVlk0BN10SffkcKVNP0gYbIzyj
LsAsPy1kyy8o1u1I9SYBbtxkjoZ0hTh5N4jYlZDF0fD5ejUtZyevNQcNuBvoW1aF
5yfPi2IOLDqoHcsVQcIJVAyWugLLDopNDhkAXWXjffwXUhr4tFZ28IwURcQop/dF
nXE5/iyVFMKBR5TENLxr
=pubu
-END PGP SIGNATURE-
___
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

named.conf Default Location?

[Tim Daneliuk]

I have two FreeBSD 10 machines on which I have installed the bind99 port.

The manpage for named on machine 1 says that it looks for the named.conf
by default in /usr/local/etc/namedb.  Machine 2's manpage says it looks
in /etc/namedb.   

Which is correct?  Is the /etc/namedb symlink even needed anymore?
----
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

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

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

Re: ISC considering a change to the BIND open source license

[Tim Daneliuk]

On 06/13/2016 03:52 PM, Victoria Risk wrote:
> Hello BIND users-
> 
> ISC published BIND under a very permissive open source license 
> <https://www.isc.org/downloads/software-support-policy/isc-license/> 
> (https://www.isc.org/downloads/software-support-policy/isc-license/) nearly 
> two decades ago.  ISC is the organizational steward for BIND; in order to 
> preserve the software for the long term, we are considering a move to the 
> more restrictive Mozilla Public License (MPL 2.0) 
> <https://www.mozilla.org/en-US/MPL/2.0/> 
> (https://www.mozilla.org/en-US/MPL/2.0/).
> 
> The MPL license requires that anyone redistributing the code who has changed 
> it must publish their changes (or pay for an exception to the license). It 
> doesn’t impact anyone who is using the software without redistributing it, 
> nor anyone redistributing it without changes – so most users will not see any 
> change. 
> 
> In the event we do proceed with the change in license, we will announce this 
> with the 9.11.0 beta and it will take effect with the BIND 9.11.0 release.
> 
> We welcome comments from BIND users, including statements of support or 
> concern.  Email Vicky Risk, Product Manager at vi...@isc.org if you want to 
> discuss privately, Tweet at us at @ISCdotORG <https://twitter.com/ISCdotORG>, 
> or discuss on bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>.
> 
> Regards,
> 
> Vicky Risk, 
> Product Manager
> 
> Jeff Osborn, President of ISC, announcing we are considering this change at 
> RIPE72 in Copenhagen May 26th, https://ripe72.ripe.net/archives/video/206.

+1

Long time bind user here and I heartily endorse this.



Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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.16.1 failing assertion

[Tim Daneliuk]

On 4/16/20 5:03 PM, arlac77 wrote:
> Hello,
> i am using
> 
> BIND 9.16.1 (Stable Release) 
> 
> on
> 
> Linux odroid1 4.14.173-1-ARCH #1 SMP PREEMPT Sun Mar 22 14:06:09 UTC 2020
> armv7l GNU/Linux
> 
> 
> after a few seconds of operation bind dumps with:
> 
> 16-Apr-2020 23:39:01.633 netmgr.c:1000: REQUIRE(worker->recvbuf_inuse)
> failed
> 16-Apr-2020 23:39:01.633 exiting (due to assertion failure)
> 
> With the former version (9.16.0?) there where no such problems
> 
> Any ideas ?
> 
> thanks & By
> Markus

Yup, that borked our entire environment today. Shame on my for not testing
in non-prod first :(

Fell back to 9.14 on FreeBSD for now.

--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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

Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

We have split horizon setup and enable our internal and trusted hosts
to do things as follows:

allow-recursion { trustedhosts; };
allow-transfer  { trustedhosts; };

'trustedhosts' includes a number of public facing IPs as well as the
192.168.0/24 CIDR block.  It also includes the IPs of the Master and
Slave bind servers.

So here's the part that has me wondering.  If I do a reverse lookup of
an IP, it works as expected _except_ if I do it on either the Master
or Slave machines. They will not only look up reverses on our
own IPs, they won't do it for ANY IP and returns the warning:

WARNING: recursion requested but not available

This is replicable with 9.14 or 9.16 (or was until today's assert borkage)
running on FreeBSD 11.3-STABLE.  Master is on a cloud server, Slave is
on a physical machine.  Neither instance is jailed.

Ideas?

-- 
----
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 7:26 AM, Bob Harold wrote:
> 
> On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk  <mailto:tun...@tundraware.com>> wrote:
> 
> We have split horizon setup and enable our internal and trusted hosts
> to do things as follows:
> 
>     allow-recursion { trustedhosts; };
>     allow-transfer  { trustedhosts; };
> 
> 'trustedhosts' includes a number of public facing IPs as well as the
> 192.168.0/24 CIDR block.  It also includes the IPs of the Master and
> Slave bind servers.
> 
> So here's the part that has me wondering.  If I do a reverse lookup of
> an IP, it works as expected _except_ if I do it on either the Master
> or Slave machines. They will not only look up reverses on our
> own IPs, they won't do it for ANY IP and returns the warning:
> 
>     WARNING: recursion requested but not available
> 
> This is replicable with 9.14 or 9.16 (or was until today's assert borkage)
> running on FreeBSD 11.3-STABLE.  Master is on a cloud server, Slave is
> on a physical machine.  Neither instance is jailed.
> 
> Ideas?
> 
> -- 
> 
> 
> Tim Daneliuk     tun...@tundraware.com <mailto:tun...@tundraware.com>
> PGP Key:         http://www.tundraware.com/PGP/
> 
> 
> Is 127.0.0.1 in the 'trustedhosts' list?

Yes

> Are you telling 'dig' what server to use  - dig @*MailScanner warning: 
> numerical links are often malicious:* 127.0.0.1 <http://127.0.0.1>

No.  But when I do, it works properly.  Doesn't dig default to localhost (in 
this case the host running bind)?

> What servers are listed in /etc/resolv.conf?  Do they resolve the reverse 
> zones?

There is no resolv.conf on these machines.  They are the ones running the 
nameservers.

> Are local queries hitting the right 'view' (if you have multiple views) ?

Yes, IF I explicitly point dig to the right nameserver.


So ... what's going on is that dig appears to not be using localhost first to 
resolve reverses.



> 
> -- 
> Bob Harold
> 


-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 9:50 AM, Bob Harold wrote:
> 
> Agree, that's odd, and not what the man page says.  Any chance that there is 
> some other DNS helper running, like resolved, nscd, dnsmasq, etc?

Nope.  This is vanilla FreeBSD with vanilla bind running.

> 'dig' should tell you what address it used, at the bottom of the output - 
> what does it say?



;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE  rcvd: 83


Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation?  (This is an IPV4 only environment).



-- 
--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 10:17 AM, julien soula wrote:
> On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:
>> On 4/17/20 9:50 AM, Bob Harold wrote:
>>>
>>> Agree, that's odd, and not what the man page says.  Any chance that there 
>>> is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
>>
>> Nope.  This is vanilla FreeBSD with vanilla bind running.
>>
>>> 'dig' should tell you what address it used, at the bottom of the output - 
>>> what does it say?
>>
>>
>>
>> ;; Query time: 0 msec
>> ;; SERVER: ::1#53(::1)
>> ;; WHEN: Fri Apr 17 09:53:51 CDT 2020
>> ;; MSG SIZE  rcvd: 83
>>
>>
>> Does the SERVER line indicate it's trying to get to the local instance via
>> IPV6 or is this just standard notation?  (This is an IPV4 only environment).
> 
> "::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
> you should add this IP to trustedhosts to check if it works.
> 
> best regard,
> 


Aha!  That was it.  What is curious to me is that bind uses this even in the 
absence
of any IPV6 in the environment.

Problem solved.  Thanks all!



-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: [Non-DoD Source] Re: BIND Masters and slaves

[Tim Daneliuk]

On 6/15/20 1:15 PM, Michael De Roover wrote:
> Of course I could, but I do not feel like the effort to change nomenclature 
> is either beneficial or worth taking for granted the requests of some people 
> on Twitter - as the slave to peer authority I am - given how much it affects 
> documentation, code, comments, general environment of the projects 
> themselves. I enjoy being surrounded by people much smarter than I am when it 
> comes to the mailing list here. Let's keep it that way and not derange 
> ourselves into meaningless blabber from social media.
> 
> What I did notice over time however that most of the projects affected are 
> also those who do have to maintain a good public image, usually corporations. 
> Meanwhile projects such as Opal  and 
> recently Rubocop  as well 
> were not. The latter one I'd like to draw attention to. The maintainer 
> clearly didn't ask for this and asked everyone who shamed him, why are you 
> doing this? None of the complainers were affiliated to the project at all. 
> Chances are that they weren't even using it and just searched for projects 
> with the name "cop" in it instead. These are not the people I want to support 
> in my effort to end racism, which I /do/ support, and quite heavily so.
> 


Hear Hear -


This isn't political.  It's just dumb.

P.S. I wish the people all spun up on terminological trivia would actually
expend their energy and activist voice to stop _real_ slavery which
goes on routinely in parts of Africa, Eastern Europe, and in China
every single day.  But trying to grasp what is happening, say, to the
Uyghurs is just way more work than your virtue card punched ...
___
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

How Zone Files Are Read

[Tim Daneliuk]

I ran into a situation yesterday which got me pondering something about bind.

In this case, a single line in a zone file was bad.  The devops automation
had inserted a space in the hostname field of a PTR record.

What was interesting was that - at startup - bind absolutely refused
to load the zone file at all.  I would have expected it to complain
about the bad record and ignore it, but load the rest of the
good records.

Can someone please explain the rationale or logic for this?  Not complaining,
just trying to understand for future reference.

TIA,
Tim
___
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: How Zone Files Are Read

[Tim Daneliuk]

On 12/16/20 11:36 AM, Reindl Harald wrote:
> 
> 
> Am 16.12.20 um 18:26 schrieb Gregory Sloop:
>> This isn't, IMO, very useful as a response to the OP.
> 
> let that decide the OP
> 
>> To sum up the response; "It's better to never fail!"
>>
>> Yes, that seems pretty obvious. It *would* be better to never fail. Way, way 
>> better.
>> But the big problem in life is; We're always failing! Dammit!
>>
>> So, learning how to gracefully fail, and understanding what happens and why, 
>> when something fails, is pretty important to achieve the outcome of; "Not 
>> failing quite so catastrophically."
> 
> loading a invalid zoen file is far away from "fail geraceful"! if a comozter 
> don't understand the input fully it's not supposed to guess
> 
>> So, while I don't have helpful knowledge to impart to the OP, I think I can 
>> say that giving the advice of "don't fail" doesn't seem very helpful.
> 
> where did i give the advice "don't fail"?
> please read my repsonse again!
> 
> * the zone fails on the master
> * the zone is still available on the slaves
> * so the error isn't fatal
> * but you recognize your mistake
> 
> what happens when the error is in the line of the MX record and named would 
> say "well, it's only one line, we still have the zone but no longer an MX"?
> 
> it would lead to a *fatal error* for the behavior of the whole zone, even if 
> *all* or your nameservers go down it would be better because every delivering 
> MTA would just queue the messages in case of a SERVFAIL
> 
> without the MX the would go to the A record of the zone which is in most 
> cases simply the wrong destination
> 

I agree that in a master-slave topology, your argument makes sense.
I this case, the server was a singleton responsible for a small virtual
private network within a much larger one. So. when the server failed to start,
the client had NO DNS for that subnet.



-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: How Zone Files Are Read

[Tim Daneliuk]

On 12/16/20 12:25 PM, Timothe Litt wrote:
> On 16-Dec-20 11:37, Tim Daneliuk wrote:
>> I ran into a situation yesterday which got me pondering something about bind.
>>
>> In this case, a single line in a zone file was bad.  The devops automation
>> had inserted a space in the hostname field of a PTR record.
>>
>> What was interesting was that - at startup - bind absolutely refused
>> to load the zone file at all.  I would have expected it to complain
>> about the bad record and ignore it, but load the rest of the
>> good records.
>>
>> Can someone please explain the rationale or logic for this?  Not complaining,
>> just trying to understand for future reference.
>>
>> TIA,
>> Tim
> 
> DNS is complicated.  The scope of an error in a zonefile is hard to determine.
> 
> To avoid this, your automation should use named-checkzone before releasing a 
> zone file.
> 
> This will perform all the checks that named will when it is loaded.
> 


Kind of what I thought.  Whoever build the environment in question
really didn't understand DNS very well and hacked together a kludge
that I am still trying to get my head around.


-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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

Multiple IPs Associated With A Single Name

[Tim Daneliuk]

In the dark and dusty reaches of my elderly DNS experience, ISTR a way to
set up A records so that the request to resolve a name returns a *list
of associated IPs*.  This is distinct from DNS RR (I think?) which 
simply returns a different *single* IP for each call (I may well be wrong).

Can some kind soul point me to a relevant explanation of how to do the
hostname -> multiple IP mapping?

Thanks,
-- 
----
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Multiple IPs Associated With A Single Name

[Tim Daneliuk]

On 09/29/2016 02:08 PM, John Miller wrote:
> Hi Tim,
> 
> AFAIK, multiple A records are the only way to return multiple IPs for
> a given FQDN.  there are multiple A records for a given name, BIND
> will return all of those records -- it'll return all the IPs.  It's up
> to the client in question to decide how to use that information.
> 
> John
>


Thanks all, for responding.

One followup question.  I am currently doing some engineering work for
GreatBigHugeCo, wherein getting things like DNS updates done is very
time and paperwork intensive.  Sometimes I think it would be easier
to do tensor analysis with an abacus, but I digress ...

For reasons too long and complex to explain, I may want to do the following
and need some input on how to implement this or whether it's even practical:

  - Run an instance of bind in user space so I can control all the 
configuration without having root.

  - Forward all lookups not in my database to a "real" DNS server


What I am stuck on is this:  Is there any simple (i.e., non-root) way
to write a client or otherwise configure userspace to go to the non-standard
port and run my sort of man-in-the-middle server?  Or is this just a stupid
idea?


-- 
--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Multiple IPs Associated With A Single Name

[Tim Daneliuk]

On 09/29/2016 04:18 PM, Tim Daneliuk wrote:
> On 09/29/2016 02:08 PM, John Miller wrote:
>> Hi Tim,
>>
>> AFAIK, multiple A records are the only way to return multiple IPs for
>> a given FQDN.  there are multiple A records for a given name, BIND
>> will return all of those records -- it'll return all the IPs.  It's up
>> to the client in question to decide how to use that information.
>>
>> John
>>
> 
> 
> Thanks all, for responding.
> 
> One followup question.  I am currently doing some engineering work for
> GreatBigHugeCo, wherein getting things like DNS updates done is very
> time and paperwork intensive.  Sometimes I think it would be easier
> to do tensor analysis with an abacus, but I digress ...
> 
> For reasons too long and complex to explain, I may want to do the following
> and need some input on how to implement this or whether it's even practical:
> 
>   - Run an instance of bind in user space so I can control all the 
> configuration without having root.
> 
>   - Forward all lookups not in my database to a "real" DNS server
> 
> 
> What I am stuck on is this:  Is there any simple (i.e., non-root) way
> to write a client or otherwise configure userspace to go to the non-standard
> port and run my sort of man-in-the-middle server?  Or is this just a stupid
> idea?
> 
> 


I forgot to mention:  At least one use case for this might be a case where
I can force the client in user space to use the DNS server and port of my
choosing.  In that case, they won't be using the system DNS config and the
above would not apply.   However, I am unclear on whether bind can be run
as an unprivileged user on a non-standard port.

-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Multiple IPs Associated With A Single Name

[Tim Daneliuk]

On 09/29/2016 04:33 PM, Matthew Pounsett wrote:
> 
> 
> On 29 September 2016 at 14:18, Tim Daneliuk  <mailto:tun...@tundraware.com>> wrote:
> 
> 
> What I am stuck on is this:  Is there any simple (i.e., non-root) way
> to write a client or otherwise configure userspace to go to the 
> non-standard
> port and run my sort of man-in-the-middle server?  Or is this just a 
> stupid
> idea?
> 
> 
> There's no way to specify a port number in a delegation, so if this is an 
> authoritative DNS server that you expect random clients on the Internet to 
> contact, it must run on port 53... so you'll need root access to start it up. 
>  I'm not aware of stub resolvers that accept port numbers in their 
> configuration either  (e.g. glibc and resolv.conf) ... although I'll admit I 
> haven't gone to double check that... but I think you're out of luck for a 
> recursive server as well.
> 
> Configuration for forwarders and stub zones can include a port number, 
> however.  So in theory you could have a server somewhere that answers on port 
> 53 forwarding queries to your server that answers on an unprivileged port.   

Yeah, kind of what I figured.

> That seems like a lot of complexity to go to in order to avoid running a name 
> server as root, though.  You'd probably be better off convincing your systems 
> people to set up sudo in such a way that you can administer a DNS server 
> running on a privileged port, and nothing else.
> 
> 

This is very, very, very hard to do.

One hope I have is that my team controls all the client-side apps code.
I want to explore the possibility of forcing that code to do lookups
to a server we control at a non-standard port that would only answer
lookups for a very narrow range of internal app servers (none of this
is on a public facing network) and forward everything else up to a real
DNS servers.




-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Multiple IPs Associated With A Single Name

[Tim Daneliuk]

On 09/29/2016 04:57 PM, Niall O'Reilly wrote:
> On 29 Sep 2016, at 22:33, Matthew Pounsett wrote:
> 
>> That seems like a lot of complexity to go to in order to avoid running a 
>> name server as root, though.  You'd probably be better off convincing your 
>> systems people to set up sudo in such a way that you can administer a DNS 
>> server running on a privileged port, and nothing else.
> 
>   If this is for testing and you control all the clients, a VM of your own,
>   perhaps under VirtualBox on your laptop, may meet your need.
> 
>   Niall O'Reilly


No, not really.  It's for a private cloud microservices system we're
thinking through.  We already run most/many of the various service
backends in user space so that the app devs and support folks can control
their own universe without having to constantly invoke someone with sudo
or root or firecall permissions.   Because of very strict audit and
regulatory constraints, there is zero chance they'll ever get root/sudo
access to the DNS config, so running our private DNS just for this
subset of private client/cloud users may make sense.

I really appreciate everyone jumping in to help with this.

-- 
--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Multiple IPs Associated With A Single Name

[Tim Daneliuk]

On 09/29/2016 04:45 PM, Darcy Kevin (FCA) wrote:
> Yeah, sure, just run it with your own special config file (with -c); in that 
> config file, set the listen-on to an unprivileged port, and make sure all of 
> the pathnames (including implicit pathnames like the pid-file) are to 
> files/directories to which the unprivileged user has read and (where 
> necessary) write access.
> 
> As a sanity check, I just fired up an instance on a Red Hat box, as an 
> unprivileged user, listening on port 12345. It's a caching-only config, with 
> our own internal-root hints, and it's resolving (internal) names just fine.
> 
>   
> - Kevin

How did you get your code to look at that instance:port rather than the
one dictated by /etc/resolv.conf or a local server on port 53?

--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Multiple IPs Associated With A Single Name

[Tim Daneliuk]

On 09/30/2016 10:12 AM, Reindl Harald wrote:
> 
> Am 30.09.2016 um 16:22 schrieb Tim Daneliuk:
>> On 09/29/2016 04:45 PM, Darcy Kevin (FCA) wrote:
>>> Yeah, sure, just run it with your own special config file (with -c); in 
>>> that config file, set the listen-on to an unprivileged port, and make sure 
>>> all of the pathnames (including implicit pathnames like the pid-file) are 
>>> to files/directories to which the unprivileged user has read and (where 
>>> necessary) write access.
>>>
>>> As a sanity check, I just fired up an instance on a Red Hat box, as an 
>>> unprivileged user, listening on port 12345. It's a caching-only config, 
>>> with our own internal-root hints, and it's resolving (internal) names just 
>>> fine.
>>>
>> How did you get your code to look at that instance:port rather than the
>> one dictated by /etc/resolv.conf or a local server on port 53?
> 
> dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-m] [-p 
> port#] [-q name] [-t type] [-v] [-x addr] [-y [hmac:]name:key] [-4] [-6] 
> [name] [type] [class] [queryopt...]

As I understand it, dig uses it's own code to determine which resolver to use, 
hence this works.

In my particular case, I am trying to figure out a way to redirect 
gethostbyname() calls
to the resolver of my choice so that existing code will run without change.  
The problem is
that I need to do this without root or sudo access to the machines in question, 
and this is
increasingly looking impossible.
___
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: Multiple IPs Associated With A Single Name

[Tim Daneliuk]

On 09/30/2016 11:17 AM, Hrant Dadivanyan wrote:
> Won't port redirection work better then ?


Yes it would, but redirecting a privileged port requires  root.

Since so many people have kindly responded here, it might be worth
explaining a bit of the backstory.

The client is a large corporate concern which very rigid compliance and
audit requirements.  This means even the simplest changes can take 
weeks or months to implement as things go through massive internal
reviews.

Meanwhile, there is an R&D team that is exploring spinning up on-demand
microservices solutions for a variety of data analytics applications 
within the firm.  They cannot get a sandbox they control and they cannot
get sudo for even limited access to things on their sandboxes.  So, we're
trying to figure out a way to work around the corporate slowness while
still living entirely in userland - this lowers the audit risk a lot.

Somewhat OT: 

I know this probably seems dumb to most people but you have to realize that
after the 2008 economic meltdown, governments all over the world - predictably -
way overreacted (and to the wrong things) and are now choking the life
out of corporations with absurd regulations that do nothing but make
things harder.  The cheaters can probably still find a way if they really
want to - it's just mildly harder.  It's good for me though - it keeps
me fully booking revenue :)

-- 
--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Multiple IPs Associated With A Single Name

[Tim Daneliuk]

On 09/30/2016 12:46 PM, John Miller wrote:
> On Fri, Sep 30, 2016 at 1:15 PM, Tim Daneliuk  wrote:
>> On 09/30/2016 11:17 AM, Hrant Dadivanyan wrote:
>>> Won't port redirection work better then ?
> 
>> get sudo for even limited access to things on their sandboxes.  So, we're
>> trying to figure out a way to work around the corporate slowness while
>> still living entirely in userland - this lowers the audit risk a lot.
> 
> Hi Tim,
> 
> Can you spin up virtual machines on your desktops?  It seems like your
> situation just screams for tools like Vagrant and Docker, or your own
> AWS/Azure/Google environment.  Yours isn't really a DNS problem, per
> se, but instead to have a proper development environment.  These days,
> it's relatively easy to stand up an entire network within VMware
> Workstation, VirtualBox, etc., or even your own local KVM instances.
> 
> John
> 


For testing purpose we've done this.  However, I was a bit cavalier
about this being just a sandbox.  There is the intent to go live with
a production version of all this stuff within a short time.  I am trying
to get ahead of that freight train ...

Again, many, many thanks to all of you who took the time here to try and
help.  It's very much appreciated.

-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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

Multiple A Records - Followup Question

[Tim Daneliuk]

As a followup to my earlier question on have a single hostname with multiple
A record, I want to understand a slightly different scenario. 3 hosts exist
with canonical A records:

hosta   A   1.2.3.4
hostb   A   5.6.7.8
hostc   A   9.10.11.12

My earlier question was whether one host could have more than one 
A record.  But say, I want to to this as follows:

testA   1.2.3.4
testA   5.6.7.8
testA   9.10.11.12

Is this legit?  IOW, can a given *IP* appear in more than one A record? I 
realize 
that this does have the problem that the reverses would resolve to hostX not 
test.


Thanks,
-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: SOA settings

[Tim Daneliuk]

On 02/02/2018 04:00 PM, Warren Kumari wrote:


> It only takes a few 2678400 seconds to get into this habit - if you
> are having a hard time adjusting, I'd recommend Kris Allen's seminal
> work - https://www.youtube.com/watch?v=PwYnG2DGbPo   
I prefer this - (slightly NFSW): https://www.youtube.com/watch?v=dQw4w9WgXcQ
___
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 > 9.12 Will Not Start On FreeBSD

[Tim Daneliuk]

Running:  FreeBSD 11.2-STABLE #0 r345904

Bind 9.11 works fine.  If I attempt to install 9.12 or greater, the
installation succeeds but any attempt to start the daemon fails silently.
Output of 'sh -x /usr/local/rc.d/named start' follows below.

Any thoughts or pointers would be deeply appreciated...

--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/



+ named_enable=YES
+ named_program=/usr/local/sbin/named
+ named_conf=/usr/local/etc/namedb/named.conf
+ named_flags=''
+ named_uid=bind
+ named_chrootdir=''
+ named_chroot_autoupdate=YES
+ named_symlink_enable=YES
+ named_wait=NO
+ named_wait_host=localhost
+ named_auto_forward=NO
+ named_auto_forward_only=NO
+ required_dirs=''
+ _named_confdirroot=/usr/local/etc/namedb
+ _named_confdir=/usr/local/etc/namedb
+ _named_program_root=/usr/local
+ _openssl_engines=/usr/lib/engines
+ rndc_conf=/usr/local/etc/namedb/rndc.conf
+ rndc_key=/usr/local/etc/namedb/rndc.key
+ run_rc_command start
+ _return=0
+ rc_arg=start
+ [ -z named ]
+ shift 1
+ rc_extra_args=''
+ _rc_prefix=''
+ eval '_override_command=$named_program'
+ _override_command=/usr/local/sbin/named
+ command=/usr/local/sbin/named
+ _keywords='start stop restart rcvar enabled describe extracommands reload'
+ rc_pid=''
+ _pidcmd=''
+ _procname=/usr/local/sbin/named
+ [ -n /usr/local/sbin/named ]
+ [ -n '' ]
+ _pidcmd='rc_pid=$(check_process /usr/local/sbin/named )'
+ _keywords='start stop restart rcvar enabled describe extracommands reload 
status poll'
+ [ -z start ]
+ [ start '=' enabled ]
+ [ -n '' ]
+ eval 'rc_flags=$named_flags'
+ rc_flags=''
+ eval '_chdir=$named_chdir' '_chroot=$named_chroot' '_nice=$named_nice' 
'_user=$named_user' '_group=$named_group' '_groups=$named_groups' 
'_fib=$named_fib' '_env=$named_env' '_prepend=$named_prepend' 
'_login_class=${named_login_class:-daemon}' '_oomprotect=$named_oomprotect'
+ _chdir='' _chroot='' _nice='' _user='' _group='' _groups='' _fib='' _env='' 
_prepend='' _login_class=daemon _oomprotect=''
+ [ -n '' ]
+ [ -z '' ]
+ eval 'rc_pid=$(check_process' /usr/local/sbin/named ')'
+ check_process /usr/local/sbin/named
+ _procname=/usr/local/sbin/named
+ _interpreter=''
+ [ -z /usr/local/sbin/named ]
+ _find_processes /usr/local/sbin/named . -ax
+ [ 3 -ne 3 ]
+ _procname=/usr/local/sbin/named
+ _interpreter=.
+ _psargs=-ax
+ _pref=''
+ [ . '!=' . ]
+ _procnamebn=named
+ _fp_args='_arg0 _argv'
+ _fp_match=$'case "$_arg0" in
\t\t
$_procname|$_procnamebn|${_procnamebn}:|"(${_procnamebn})"|"[${_procnamebn}]")'
+ _proccheck=$'\t\t/bin/ps -ww 2>/dev/null -o pid= -o jid= -o command= -ax |
\t\twhile read _npid _jid _arg0 _argv; do
\t\t\tcase "$_arg0" in
\t\t
$_procname|$_procnamebn|${_procnamebn}:|"(${_procnamebn})"|"[${_procnamebn}]")
\t\t\t\tif [ "$JID" -eq "$_jid" ];
\t\t\t\tthen echo -n "$_pref$_npid";
\t\t\t\t_pref=" ";
\t\t\t\tfi
\t\t\t\t;;
\t\t\tesac
\t\tdone'
+ eval /bin/ps -ww '2>/dev/null' -o 'pid=' -o 'jid=' -o 'command=' -ax '|' 
while read _npid _jid _arg0 '_argv;' do case '"$_arg0"' in 
'$_procname|$_procnamebn|${_procnamebn}:|"(${_procnamebn})"|"[${_procnamebn}]")'
 if [ '"$JID"' -eq '"$_jid"' '];' then echo -n '"$_pref$_npid";' '_pref="' '";' 
fi ';;' esac done
+ /bin/ps -ww -o 'pid=' -o 'jid=' -o 'command=' -ax
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ r

Re: Bind > 9.12 Will Not Start On FreeBSD

[Tim Daneliuk]

On 4/27/19 3:33 PM, Anand Buddhdev wrote:
> On 27/04/2019 21:52, Tim Daneliuk wrote:
> 
> Hi Tim,
> 
>> Running:  FreeBSD 11.2-STABLE #0 r345904
>>
>> Bind 9.11 works fine.  If I attempt to install 9.12 or greater, the
>> installation succeeds but any attempt to start the daemon fails silently.
>> Output of 'sh -x /usr/local/rc.d/named start' follows below.
> 
> This doesn't show anything useful. BIND usually logs to syslog when
> starting up. Check your syslog - you may find more useful messages in there.
> 
> Regards,
> Anand
> 

D'oh ... I didn't even think of that (and I should have).

It appears to have been a file ownership problem with some files in
/usr/local/etc/named ... but it's weird.  First of all, all files in there
were group and world readable.  Why is 9.12+ now suddenly so grumpy about
who owns the files?  Is this a recent fix to reduce the attack surface
on files owned by root?

-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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.12 Will Not Start On FreeBSD

[Tim Daneliuk]

On 4/27/19 5:33 PM, @lbutlr wrote:
> On 27 Apr 2019, at 16:21, Tim Daneliuk  wrote:
>> Why is 9.12+ now suddenly so grumpy about who owns the files?  Is this a 
>> recent fix to reduce the attack surface on files owned by root?
> 
> Pretty sure. I thought it was mentioned in the 9.12 release notes, but now I 
> can't find it.
> 
> 

Possibly relevant:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223842

-- 
--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
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: Proposal to adopt a Code of Conduct for the list

[Tim Daneliuk]

On 8/2/19 1:31 PM, Victoria Risk wrote:
> This list is a tremendously helpful and generous group that has provided 
> really invaluable assistance 

tl;dr  Discuss the topic, not each other

It's tragic this even has to be said ...
___
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: I am provoked by ISC for the 10 years statement that ISC refuse to fulfill (Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?)

[Tim Daneliuk via bind-users]

On 2/11/24 02:07, Ole Aamot wrote:

"This whole “we support everything for 10 years” is just a sales pitch, not a 
something that can be fulfilled." – Ondřej Surý — ISC




I realize that there was a whole kerfuffle here that I mercifully missed and
have absolutely no interest in.

But it did "provoke" a question.  Does anyone think not restarting *anything* 
for 10 years
is a good idea?

I realize there were all these fanbois back in the day that wanted to prove
*NIX could stay up longer and with greater stability than Windows.   But best 
practices
would suggest that you patch and restart monthly at a minimum and more often for
zero-days and more immediate threats.  I would include among this the OS itself
as well as key infrastructure services.

Oh, and for the record, I think ISC does a very fine job ;)

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

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


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

TXT & SPF Record Syntax

[Tim Daneliuk via bind-users]

I am trying to understand when the LHS of a TXT record needs to be terminated 
with '.'.

For example, I see this one of the machines I am managing.  The server in 
question is
the zone authority for foo.com:

foo.com. IN TXT "v=spf1 ...
foo.com. IN SPF "v=spf1 ...
something._domainkey IN TXT "v=DKIM1 ...
_dmark.foo.com.  IN TXT "v=DMARC1 ...

Could some kind soul explain why the DKIM key name does not require the 
trailing period, but
why all the foo.com entries do?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: TXT & SPF Record Syntax

[Tim Daneliuk via bind-users]

On 2/28/21 5:52 PM, Mark Andrews wrote:
> Domain names without a trailing period are relative to the current origin.
> 
> Domain names with a trailing period are absolute.
> 
> If you want to add the record
> 
>   foo.bar.example.com. TXT …
> 
> and the current origin is example.com. You can enter it as
> 
>   foo.bar TXT …
> 
> or
> 
>   foo.bar.example.com. TXT …
> 
> or you could set the origin to bar.example.com. and do this
> 
>   $ORIGIN bar.example.com.
>   foo TXT …
> 
> This applies to all domain names in zone files.
> 
> Mark

OK that makes sense.  Thanks.  It's been so long since I configured these 
servers - and
they have worked so flawlessly - I forgot everything I knew about bind config 
files ;)
___
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

Corrupted Slave Data?

[Tim Daneliuk via bind-users]

Running bind 9.16.15 on FreeBSD 11.4-STABLE.

Master is out on a cloud server at Digital Ocean.  Slave is on-premise.
All on-prem LANs point to the slave instance.

Running split horizon to keep nosey parkers out of our local DNS assignments.

Recently - and for no obvious reason - the on-prem instance stops resolving
properly.  The fix is to stop it, clear out the slave files, and restart.
Then it works for a few days and repeats its misbehavior.

The logs show nothing remarkable, at least at first look.

Is there a known slave file corruption problem?

Could someone kindly suggest things we could look into otherwise?

Many Thanks ...
___
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: Corrupted Slave Data?

[Tim Daneliuk via bind-users]

On 5/20/21 8:43 AM, Anand Buddhdev wrote:
> On 20/05/2021 15:30, Tim Daneliuk via bind-users wrote:
> 
> Hi Tim,
> 
>> Recently - and for no obvious reason - the on-prem instance stops resolving
>> properly.  The fix is to stop it, clear out the slave files, and restart.
>> Then it works for a few days and repeats its misbehavior.
>>
>> The logs show nothing remarkable, at least at first look.
>>
>> Is there a known slave file corruption problem?
>>
>> Could someone kindly suggest things we could look into otherwise?
> 
> This is not a useful report at all. Your statement, "the on-prem
> instance stops resolving properly", provides absolutely no useful
> information about the failure. You haven't provided any configuration
> details either. All you're saying is "I have a problem. Help!" We are
> not mind-readers, and can't even begin to imagine what might be wrong.
> 
> If you provide more details about your configuration, and about what
> kind of failure you're observing (dig queries and responses, for
> example), then perhaps some people might be able to assist you.
> 
> Regards,
> Anand


Fair enough.  Although I was just curious about known slave file corruption
issue, for now.   When this happens again, I will do digs and submit deets here.

Thanks
___
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: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Tim Daneliuk via bind-users]

On 8/10/21 7:51 AM, Matthijs Mekking wrote:
> Hi Klaus,
> 
> On 10-08-2021 13:38, Klaus Darilion wrote:
>> Hi Matthijs!
>>
>>> We would like to encourage you to change your configurations to 
>>> 'dnssec-policy'. See this KB article for migration help:
>>>
>>> https://kb.isc.org/docs/dnssec-key-and-signing-policy
>>
>> Some comments to this KB article and dnssec-policy:
>>
>> - The article should mention how to retrieve the DS record from
>> Bind.


So just to be sure I'm doing the right thing, I've added this to my
options stanza:

dnssec-policy "default";

Then restarted named and now all the signing magic is taken care of for
me for all zones?  (I was not previously using signing.)

TIA,

-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
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: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Tim Daneliuk via bind-users]

On 8/10/21 10:07 AM, Matthijs Mekking wrote:
>> So just to be sure I'm doing the right thing, I've added this to my
>> options stanza:
>>
>>  dnssec-policy "default";
>>
>> Then restarted named and now all the signing magic is taken care of for
>> me for all zones?  (I was not previously using signing.)
> 
> Correct.
> 
> But you still need to manually submit the DS record to your registrar/parent 
> and if you see the DS published run:
> 
> rndc dnssec -checkds published .



I've never done any of the signing work before (other than for  master/slave).
Could you kindly point me to something like

  "DS Record Creation And Implementation For Dummies"?

Thanks,

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
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: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Tim Daneliuk via bind-users]

On 8/10/21 7:32 PM, raf via bind-users wrote:
> To get the DS record information to convey to the
> registrar, after starting to use the default policy.
> look for the CDS record (the child version of the DS
> record) with dig:
> 
>   dig CDS EXAMPLE.ORG
> 
> For the default policy, you'll only have to do this
> once (or until your server gets compromised and you
> start again). But until you've done this, it's not
> done. The trust chain has to go all the way to the
> root, so you need the involvement of your registrar
> (to get your DS published and signed).


That's quite helpful, thanks, but still unclear about one
thing.  When I run the dig command above I do get a result
back with a "COOKIE" value in the response.  This value
changes each time I run the dig.   Is any one of these the
"DS record" I want to convey to my registrar?

Other than this I see nothing that resembles  a relevant response AND
the COOKIE field does not show up if I do the dig from outside the zone.



-- 
----
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
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

Debug Approach Help?

[Tim Daneliuk via bind-users]

I am running bind 9.16.19 on two FreeBSD 13-STABLE instances.  The master
is on a Digital Ocean droplet and works fine.  The slave is hosted on
physical machine here in our offices.

This has always worked flawlessly until recently.   Periodically, the slave
refuses to resolve names like 'git.freebsd.org' and we have to restart bind
on the slave to get it working correctly again.

Rather than using cron to restart bind every hour (!), we'd like to get to
the root of the problem.  The slave machine is at the end of a Comcast
Business pipe and their execrable security edge garbage may be implicated.

We could use some help on an approach to debugging this.  Having never had
significant bind problems over 20 years of use, we literally have no named
debugging experience...

TIA,
-- 
--------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
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: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Tim Daneliuk via bind-users]

On 8/10/21 11:27 PM, raf via bind-users wrote:
> Does that help at all?

Very much thank you.  I have now discovered my DNS key and corresponding DS
record.   I believe the DS record is what I have to provide my registrar
as I understand it.


-- 
----
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
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: Debug Approach Help?

[Tim Daneliuk via bind-users]

On 8/11/21 12:49 PM, Richard T.A. Neal wrote:
> There's a very good article on the ISC website which discusses BIND logging:
> https://kb.isc.org/docs/aa-01526
> 
> I recommend reading and implementing the logging as per their suggestion 
> (backup or make a note of your current logging configuration options in case 
> you want to revert in future) and then start looking through those logs the 
> next time your on-prem slave stops resolving.
> 
> Once you spot any errors in the look you can post them here on the list and 
> others will try and help explain what may be happening.
> 
> Richard.

Perfect, will do, and thanks...
-- 
----
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
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

Tracking Down Odd bind Behavior

[Tim Daneliuk via bind-users]

I have a bind slave instance running on FreeBSD 13-STABLE.  Periodically (after
a few days of perfect operation), it loses its ability to resolve at
least some names - in this case, git.freebsd.org.  When I look at the logs, I 
see this:

==> /var/log/named/query-errors <==
14-Aug-2021 16:48:33.376 query-errors: info: client @0x80949d560 
127.0.0.1#30170 (git.freebsd.org): view internal: query failed (failure
) for git.freebsd.org/IN/ at query.c:7376


An rndc flush or complete restart of this slave instance fixes the problem.

The installed version details follow.  Helpful hints to fix would be
welcome:


Aug 14 17:07:03 ozzie named[32292]: starting BIND 9.16.19 (Stable Release) 

Aug 14 17:07:03 ozzie named[32292]: running on FreeBSD amd64 13.0-STABLE 
FreeBSD 13.0-STABLE #0 stable/13-n246370-74ff46ac172: Sun Jul 1
8 12:02:34 CDT 2021 
t...@ozzie.tundraware.com:/usr1/obj/usr1/13-stable/amd64.amd64/sys/OZZIE
Aug 14 17:07:03 ozzie named[32292]: built with '--disable-linux-caps' 
'--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--wit
h-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' 
'--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' 
'--disable-dn
stap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' 
'--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--
disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' 
'--without-python' '--disable-querytrace' '--enable-tcp-fastopen'
'--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' 
'--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd13
.0' 'build_alias=amd64-portbld-freebsd13.0' 'CC=cc' 'CFLAGS=-O2 -pipe 
-DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/inclu
de -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c 
-fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PL
UG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
Aug 14 17:07:03 ozzie named[32292]: running as: named -4 -u bind -c 
/usr/local/etc/namedb/named.conf
Aug 14 17:07:03 ozzie named[32292]: compiled by CLANG FreeBSD Clang 11.0.1 
(g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff7
5f2c3fe)
Aug 14 17:07:03 ozzie named[32292]: compiled with OpenSSL version: OpenSSL 
1.1.1k-freebsd  25 Mar 2021
Aug 14 17:07:03 ozzie named[32292]: linked to OpenSSL version: OpenSSL 
1.1.1k-freebsd  25 Mar 2021
Aug 14 17:07:03 ozzie named[32292]: compiled with libxml2 version: 2.9.12
Aug 14 17:07:03 ozzie named[32292]: linked to libxml2 version: 20912
Aug 14 17:07:03 ozzie named[32292]: compiled with json-c version: 0.15
Aug 14 17:07:03 ozzie named[32292]: linked to json-c version: 0.15
Aug 14 17:07:03 ozzie named[32292]: compiled with zlib version: 1.2.11
Aug 14 17:07:03 ozzie named[32292]: linked to zlib version: 1.2.11
Aug 14 17:07:03 ozzie named[32292]: 

Aug 14 17:07:03 ozzie named[32292]: BIND 9 is maintained by Internet Systems 
Consortium,
Aug 14 17:07:03 ozzie named[32292]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit
Aug 14 17:07:03 ozzie named[32292]: corporation.  Support and training for BIND 
9 are
Aug 14 17:07:03 ozzie named[32292]: available at https://www.isc.org/support
Aug 14 17:07:03 ozzie named[32292]: 

Aug 14 17:07:03 ozzie named[32292]: command channel listening on 127.0.0.1#953
Aug 14 17:07:03 ozzie named[32292]: 14-Aug-2021 17:07:03.167 general: notice: 
all zones loaded
Aug 14 17:07:03 ozzie named[32292]: 14-Aug-2021 17:07:03.167 general: notice: 
running

TIA,

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
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: Tracking Down Odd bind Behavior

[Tim Daneliuk via bind-users]

On 8/15/21 9:07 AM, G.W. Haywood via bind-users wrote:
> Hi there,
> 
> On Sun, 15 Aug 2021, Tim Daneliuk wrote:
> 
>> I have a bind slave instance running on FreeBSD 13-STABLE.  Periodically 
>> (after
>> a few days of perfect operation), it loses its ability to resolve at
>> least some names - in this case, git.freebsd.org. ...
>> ...
>> Aug 14 17:07:03 ozzie named[32292]: running as: named -4 -u bind -c 
>> /usr/local/etc/namedb/named.conf
>> ...
> 
> Wild guess: try running without '-4'?
> 
> Otherwise, see "Troubleshooting" in the ARM.  Then, assuming that
> you've set up the logging as per the ARM to be sufficiently verbose,
> wait until the resolution failures start happening again and post
> relevant extracts.
> 


I did have extensive logging setup but only had info level recorded.  I've
since updated this to debug 3 per the ARM.  Let's see what they provides.

-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
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

Failing DNS Server Diagnostic Help Requested

[Tim Daneliuk via bind-users]

Environment:  Master/Slave with Split Horizon both on FreeBSD-STABLE
  Bind 9.16.24_1
  Master out in a cloud server
  Slave on a physical server with a static IP on Comcast Business

Problem:  After years of stable behavior, Slave intermittently not resolving
  addresses a few months ago, and then completely stopped working
  yesterday. We also noticed that the Slave will not update its files
  upon notify from the Master.

Action Taken: Replaced Slave with a clone of the Master instance.  That new
  Master does properly resolve names inside our zone, whether
  the requestor is on our LAN our one of our trusted servers out
  on the internet that are allowed to see internal names.

  HOWEVER, that new master instance will not resolve names in
  zones other than ours.  We're working around this by
  forwarding these failed lookups to our original master -
  that is working fine.

  So, we have two masters with the same configuration and
  tables, but one resolves outside names and one does not.
  We've tried disabling DNSSEC validation and opening up our
  firewalls and got nowhere.

  When the lookups outside our zone fail, we see this:

13-Jan-2022 14:28:09.702 resolver: notice: DNS format error from 
192.203.230.10#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.702 lame-servers: info: FORMERR resolving './NS/IN': 
192.203.230.10#53
13-Jan-2022 14:28:09.721 resolver: notice: DNS format error from 
192.36.148.17#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.721 lame-servers: info: FORMERR resolving './NS/IN': 
192.36.148.17#53
13-Jan-2022 14:28:09.741 resolver: notice: DNS format error from 
193.0.14.129#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.741 lame-servers: info: FORMERR resolving './NS/IN': 
193.0.14.129#53
13-Jan-2022 14:28:09.763 resolver: notice: DNS format error from 199.7.91.13#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.763 lame-servers: info: FORMERR resolving './NS/IN': 
199.7.91.13#53
13-Jan-2022 14:28:09.781 resolver: notice: DNS format error from 
202.12.27.33#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.781 lame-servers: info: FORMERR resolving './NS/IN': 
202.12.27.33#53
13-Jan-2022 14:28:09.801 resolver: notice: DNS format error from 199.7.83.42#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.801 lame-servers: info: FORMERR resolving './NS/IN': 
199.7.83.42#53
13-Jan-2022 14:28:09.820 resolver: notice: DNS format error from 
192.58.128.30#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.820 lame-servers: info: FORMERR resolving './NS/IN': 
192.58.128.30#53
13-Jan-2022 14:28:09.837 resolver: notice: DNS format error from 198.41.0.4#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.837 lame-servers: info: FORMERR resolving './NS/IN': 
198.41.0.4#53
13-Jan-2022 14:28:09.855 resolver: notice: DNS format error from 
198.97.190.53#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.855 lame-servers: info: FORMERR resolving './NS/IN': 
198.97.190.53#53
13-Jan-2022 14:28:09.875 resolver: notice: DNS format error from 192.5.5.241#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.875 lame-servers: info: FORMERR resolving './NS/IN': 
192.5.5.241#53
13-Jan-2022 14:28:09.893 resolver: notice: DNS format error from 
192.112.36.4#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.893 lame-servers: info: FORMERR resolving './NS/IN': 
192.112.36.4#53
13-Jan-2022 14:28:09.921 resolver: notice: DNS format error from 
199.9.14.201#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.921 lame-servers: info: FORMERR resolving './NS/IN': 
199.9.14.201#53
13-Jan-2022 14:28:09.937 resolver: notice: DNS format error from 192.33.4.12#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.937 lame-servers: info: FORMERR resolving './NS/IN': 
192.33.4.12#53
13-Jan-2022 14:28:09.938 resolver: info: resolver priming query complete


So ... could this be Comcast munging about in the DNS traffic?   Other 
suggestions
of where to look appreciated as well ...


(We have a fair bit of other logging data to be examined, I just didn't want to
spam the whole list with all that ...)


-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this

Bind: Standard Ports And Non Standard Ports

[Tim Daneliuk via bind-users]

After some months of poking around, we are now certain that our so-called 
"Business"
service from Comcast is compromising our DNS servers because of their
execrable "Security Edge" garbage.  (They are willing to remove this 'service'
only if we are willing to incur a higher monthly recurring fee.)

Our master is in the wild and works fine, but the slave is behind the 
compromised
Comcast pipe.  The effect of having Security Edge in place is that the
slave cannot get updates from the master and is also unable to resolve
anything outside our own zone.   Comcast is apparently hijacking all port
53 requests and doing unspeakable things with them.

Is there a way to have these servers work as usual, listening to resolution
request on port 53, but have the slave update AND forward requests to the
master over a non-standard port, so as to work around the Comcast madness?

TIA,
Tim

P.S. My guess is that this so-call "security" service is no such thing, or at
 least its not the only thing.  They are probably harvesting DNS lookups
 to sell as marketing data, or at least that would be my first guess.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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