Re: Documentation on readthedocs - links to older releases return 404 errors

[Dan Mahoney]

> On May 31, 2023, at 12:25 PM, Petr Špaček  wrote:
> 
> On 31. 05. 23 18:08, E R wrote:
>> If you visit https://bind9.readthedocs.io/en/v9.18.15/ 
>>  you will see a menu in the lower 
>> left corner where you can select older releases of the bind ARM manual.  But 
>> those links do not work and return a 404.  Should those links work?  Or do 
>> they need to be removed?
> 
> The links from the menu I tried at random work for me. Which particular 
> version is giving you trouble?
> 
>> In my case I visited https://kb.isc.org/docs/aa-01031 
>>  which pointed me to the right location to 
>> get a PDF copy of other releases and pointed me to the sources location 
>> where I can get the PDF that matches my distribution's version.
> 
> While reading you message I realized that we messed it up and old links with 
> underscore (e.g. v9_18_10 as opposed to v9.18.10) indeed do not work.
> 
> I'll see if we can restore the old links, but I cannot promise any specific 
> timeline.

Hey there FastEddie, I’m Dan with ISC’s SysAdmin team.  I normally work on the 
F-root side of the house and don’t usually chime in on bind-users, unless I’m 
working on mailman itself.

There are actually a couple of problems here, and I’d like to ask for your 
help, and that of the community.

First, there is the fact that (as Petr points out) at one point we had links 
with underscores versus dots.  We can fix those (when we know about them) by 
adding redirects inside ReadTheDocs (RTD, hereafter).  It’s tedious to create 
them for every iteration where vx_y_z does not exist but vx.y.z does, but 
that’s what might be necessary.  RTD is not smart enough to be told to “on 404, 
just jump to this version”, we have to create it for every version where this 
breakage happens.  We can create a custom 404 page, but not classic 
apache-style mod-rewrite redirects with wildcarding.

Second, I tried this with a version I had found on google: /en/v9_16_12/ and 
created a redirect to /en/v9.16.12/, which did exist inside ReadTheDocs, but 
that url was also 404ing because of a bad build due to a bad requirements.txt 
file.  So in that case, the best thing I could do was point the redirect at the 
oldest known *working* version of the docs (/en/v9.16.16/ in that case).  
You’ll notice 9.12.16 doesn’t show up in the list of available doc trees on 
RTD.  Now, is there a lot of change delta between 9.16.12 and 9.16.16?  
Probably not.  It’s better than handing out a 404.  This feels reasonable.

Finally, I realized that we’d like to be able to see what things out there in 
the world (and in Google’s caches) are referring to us, but because we don’t 
control the bind9.readthedocs.io domain, it’s a little harder to add it to our 
Google search console.  (Can’t put a CNAME record in, can’t upload an arbitrary 
.html file — and to add Meta tags, we’d have to do something “special” without 
adding that meta tag to ALL our docs).  RTD also doesn’t seem to give us server 
logs of what queries we’ve served up 404’s to.  We hope to fix that soon, but 
it’s not going to be instant.

===

I’m not sure if it’s a good use of engineer time to constantly be fixing 
failing-to-build versions of old documentation (like #2,  the 9.16.12 problem, 
above).  Creating the redirect solves the problem today, albeit in a slightly 
imperfect way, and we may be pushing fixes and/or creating redirects for stuff 
nobody’s actually linking to/reading.  (We’ll know that more when we solve #3)

So here’s where you (and others) can help with problem #3:  Please do report 
these if you see them!  I’m not sure if it’ll drive the bind9 folks crazy if 
you create gitlab issues, but do know we’ve seen this and we’re working on it.

Best,

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Mailing list questions (DMARC, ARC, more?)

[Dan Mahoney]

> On Sep 27, 2022, at 02:50, Alessandro Vesely  wrote:
> 
> Hi Dan,
> 
> 
> On Sat 24/Sep/2022 01:10:12 +0200 Dan Mahoney wrote:
>>> On Aug 23, 2022, at 07:39, G.W. Haywood via bind-users 
>>>  wrote:
>>> On Tue, 23 Aug 2022, Alessandro Vesely wrote:
>>>> I see the list operates both From: munging and ARC sealing.  While I'm 
>>>> clear about the former, I'm curious about how ARC works:
>>>> Do any subscribers trust the seal by isc.org?
>>> We check the ARC seal and I would be alerted to a failure.  That's all.
>>>> Are there other advantages that ARC brings about?
>>> It's a comfort to know that it's all working as designed, but I can't
>>> get excited about munged addresses.
>>>> Otherwise, RFC9057 introduced the Author: header field.  Using it to save 
>>>> the original From: would allow trusting receivers to de-munge the message 
>>>> at a later stage.
>>> I'm happy to use cut'n'paste for replies, but I can offer to help you
>>> with your testing.  The milters here can do more or less anything. :)
>> Hey there GW (and others).
>> [...]
>> * We're trying not to deal with the blowback that would occur if we *just 
>> decided to* one day start munging everyone's mail addresses.  Lots of people 
>> would start posting about not-bind-things.  Like this :)
> 
> 
> I apologize again for wasting bandwidth on non-DNS issues.
> 
> While munging everyone would look more coherent, I propose to stop munging 
> everyone, at least as an option for those recipient who accept broken DMARC.
> 
> 
>> * Mailman 2.x (which we run) has some sender-munging features that have been 
>> necessary in the past to ensure delivery, but they haven't been the only 
>> problem.  We're presently only doing those on domains with p=reject (or 
>> p=quarantine, which is rare).
> 
> 
> ARC was designed to avoid this.

Yes, and we're arc-sealing in the event that it catches on, but right now 
nobody seems to be paying attention to it.  We're a "there's an RFC for it, we 
should do it" kind of company, so...why not.  As a list admin, I'm most in 
favor of deliverability.

>> [...]
>> DKIM Validation/Arc Sealing:
>> * Everything gets validated at our MXes.
> 
> 
> However, the list doesn't seem to apply DMARC policies on entry.

Yes, because we're still ISC, and we still have a bunch of users on a bunch of 
non-isc mailing lists, which may themselves be breaking DMARC for those 
administrative domains.  Chicken, meet egg.

OpenDMARC's failure rejection policy is not configurable per receiving domain.

> Can internal handoff modify the message?  (Except Mailman, I mean.)

It can.  For example, a canonical rewrite map can modify the original to: 
header.

> What I want to ask is to experiment sending messages without From: munging.  
> That would entail setting up a twin mailing list, configured to not do From: 
> munging.  Users would subscribe to the latter if their MX accepts broken 
> DMARC, possibly because of ARC, or some other authentication, or even no 
> authentication check at all; presumably users who can get their hands on 
> their MTA, not Gmail accounts.  The idea is outlined as the first one of 
> three methods to get rid of From: munging, here:
> https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform

I'm loathe to do more mailman tweaking, but I'll have a read.  No promises.  
The problem is that some places might see things that are unmunged and don't 
respect arc yet and say "gee, lists.isc.org is sending us a lot of spam, let's 
block them."  Ask me how I know.

Best,

-Dan



signature.asc
Description: Message signed with OpenPGP
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://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: Mailing list questions (DMARC, ARC, more?)

[Dan Mahoney]

> On Aug 23, 2022, at 07:39, G.W. Haywood via bind-users 
>  wrote:
> 
> Hi there,
> 
> On Tue, 23 Aug 2022, Alessandro Vesely wrote:
> 
>> I see the list operates both From: munging and ARC sealing.  While I'm clear 
>> about the former, I'm curious about how ARC works:
>> Do any subscribers trust the seal by isc.org?
> 
> When it comes to email, I don't trust *anything*. :)
> 
> Generally speaking I think these technological fixes are very much
> over-engineered as compared with, say, inspecting the headers. :/
> 
> We check the ARC seal and I would be alerted to a failure.  That's all.
> There have been two failures since ISC implemented ARC - the first two
> ARC-signed messages we received, on 25th April - all after that passed:
> 
> Date: Mon, 22 Aug 2022 12:00:00 +
> X-ARCverify: pass (All ARC Seals and the most recent ARC Signature passed 
> verification)
> 
> There were a few DKIM failures in the early days too, I don't remember
> if I investigated any of the failures.
> 
>> In that case, do they get non-munged messages?
> 
> Nope.  I'm on the digest list anyway.
> 
>> Are there other advantages that ARC brings about?
> 
> It's a comfort to know that it's all working as designed, but I can't
> get excited about munged addresses.  I've experienced no issues on the
> BIND list to which I've thought ARC might be relevant.  Unfortunately
> that's by no means the case for some of the other lists to which I am
> (or have in the past been) subscribed.
> 
>> Otherwise, RFC9057 introduced the Author: header field.  Using it to save 
>> the original From: would allow trusting receivers to de-munge the message at 
>> a later stage.  I'm trying to elaborate a draft[*] to formalize such method. 
>>  Would this list be interested in experimenting that?
> 
> I'm happy to use cut'n'paste for replies, but I can offer to help you
> with your testing.  The milters here can do more or less anything. :)

Hey there GW (and others).  I apologize for this post in the top of the thread, 
but I've been traveling most of the summer and wanted to delurk and offer to 
answer questions directly.

I'm the person who implemented the arc-sealing on bind-users (and on everything 
inside isc.org many months ago), and I should demystify my logic here, with 
some use-cases that are special to ISC.

* lists.isc.org is a pretty old list.  bind-users predates the existence of 
gmail.  We've in the past hit delivery issues to gmail (often over v6 while v4 
works, it's resulted in us having to block v6 delivery to gmail) and gmail's 
auth requirements are pretty strict.

* We're trying not to deal with the blowback that would occur if we *just 
decided to* one day start munging everyone's mail addresses.  Lots of people 
would start posting about not-bind-things.  Like this :)

* Mailman 2.x (which we run) has some sender-munging features that have been 
necessary in the past to ensure delivery, but they haven't been the only 
problem.  We're presently only doing those on domains with p=reject (or 
p=quarantine, which is rare).

* There is not feature parity between mailman 2.x and mailman 3.x, and my 
personal opinion is that it's not well-done.  I'm not the only person with this 
opinion.

* We also run a public-facing github server, we've also got a few servers in 
our netblocks that are outside our control (often, personal employee vms, but 
occasionally, research projects), we have a lot of peering email, etc, and 
we're largely self-hosted.   Deliverability is important to us.

* I have some responsibilities with the Trusted Domain Project.  Recent 
releases to opendmarc, and triaging of some of the bugs there are a 
side-project that ISC is happy to loan me to.  I'm not a BIND developer, and C 
is not my strong point -- I'm more of a sysadmin, but considering nobody is yet 
rejecting messages on arc-seals, setting up arc-sealing for a mailing list with 
no real SLA to speak of is not a bad thing.  So yes, some of this is attempting 
to have ISC eat the trusted domain project's own "dog food".

Here's the workflow (though it's, once again, woefully off-topic for 
bind-users):

DKIM Validation/Arc Sealing:

* Everything gets validated at our MXes.  It would have to be, because only the 
MX has access to the IP address info required to check SPF.  From there, the MX 
applies an arc-seal that should validate wherever in the world the mail goes, 
either on to our internal mail servers, or forwarded out to gmail from one of 
our users.  We don't validate our own internal arc-seals, because we trust our 
own internal networks.  (In openarc parlance, we're using mode "sv" but 
InternalHosts causes the validation to not be applied)

DKIM:

* We run internal DKIM signing on the boxes where the mail originates.  Most of 
the time, the "Selector" is a modification of the hostname for the signing 
machine.  I wanted something easy to read and look for in the headers, so in 
most cases rather than a GUID I used a different scheme that's eas

Re: Supporting LOC RR's

[Dan Mahoney]

I have in the past considered that putting these kinds of records in for 
anycast nodes (such as, but not limited to root DNS servers), so that a person 
can glean how far they are from the node serving them (gleaned via 
hostname.bind or NSID), would be useful and fun science, in that in this way 
all the info you need would be “in the DNS”.

The fun derivation of “shortest distance with highest latency” is a fun 
exercise for the audience.

-Dan

> On May 3, 2022, at 3:07 AM, Tony Finch  wrote:
> 
> Timothe Litt  wrote:
>> On 02-May-22 09:02, Stephane Bortzmeyer wrote:
> 
>>> Fun is a sufficient reason.
>> 
>> I would never discourage anyone from having (harmless) fun.
>> 
>> On the other hand, unless your codes postaux are spherical (or a circular
>> projection), your LOC will be at best an approximation of a point in the
>> postal zone.
> 
> At my previous job there used to be a TXT record at cam.ac.uk saying
> "The University of Cambridge", which I replaced with a LOC record to avoid
> interference with things like SPF and domain authentication. It's also
> used as a test record by the keepalived health check scripts.
> 
> Cambridge has a residency rule for students that requires them to live
> within 3 miles of the city centre, so the 10km diameter in the LOC record
> is in some sense correct and reasonably accurate.
> 
> cam.ac.uk  LOC  52 12 19.000 N 0 7 5.000 E 18.00m 1m 100m 100m
> 
> -- 
> Tony Finch(he/they)  Cambridge, England
> Lundy, Fastnet, Irish Sea: Variable becoming southwest, 2 to 4. Smooth
> or slight. Occasional rain or drizzle, fog patches in Irish Sea.
> Moderate or good, occasionally very poor in Irish Sea.
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://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

Testing, please ignore

[Dan Mahoney (Gushi)]

Testing, please ignore.

-Dan

--


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

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


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

testing, please ignore

[Dan Mahoney (Gushi)]

Sorry for the noise

--

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

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


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

test, please ignore

[Dan Mahoney (Gushi)]

Thanks, subject is all.

--

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.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

Is anyone here forwarding your bind-users messages to gmail or a google-hosted domain?

[Dan Mahoney]

Hey all,

I'm one of the people who admins ISC's mail servers, and also receives all 
our DKIM/SPF/DMARC failure reports.  (We use dmarcian.com)

We've seen a number of messages reported to us as having an isc.org "from" 
address, and as having our dkim signatures, but the signatures failing to 
verify, perhaps because a forwarder may have added a subject tag or 
rewritten some other header.  Of course, SPF also fails because those 
servers aren't in our SPF record.

This makes us look bad because it shows isc.org messages arriving at gmail 
in a non-compliant way, and it makes your mail servers look bad, because 
they're "spoofing" isc.org mail.

Worse, if ISC moves our dmarc record to a p=reject policy, you just won't 
get that email anymore, so it's definitely not future-proof.

Our dmarc reports only show us aggregates of the from/to/spf/dkim/dmarc 
status.  We can't easily inspect individual messages.

If this sounds like you, please do drop me a line privately at 
dmaho...@isc.org.  I'd love to work with you to ensure I understand what's 
going on and also see if we can make things work better for everyone.

Cheers,

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

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

[Dan Mahoney]

> On Jan 25, 2022, at 8:50 AM, Benny Pedersen  wrote:
> 
> On 2022-01-25 17:45, Greg Choules wrote:
>> Hello.
> 
> Authentication-Results: lists.isc.org;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> dont know why it failed

I may as well answer this since other people chimed in on the test message.  
I'm Dan Mahoney, ISC's sysadmin who runs most of our mail systems, and, 
coincidentally, also do some work with the Trusted Domain Project on opendkim 
and opendmarc.

The headers you cite are lying to you.  :) The message passed DKIM on the way 
IN to lists.isc.org <http://lists.isc.org/> (the dedicated vm that runs our 
lists), but then, when the message got to the mailman python scripts and then 
shot back out via the MTA, they had an altered body and no longer passed, and 
the header was rewritten to say "fail".  (This is visible from the logging on 
the servers, but nowhere else).

The solution here, is that lists.isc.org <http://lists.isc.org/> should only be 
running in "signer" mode, and not verifying anything (we verify messages on our 
MXes, and make the decisions there to reject if dmarc says to do so).  The only 
things that lists.isc.org <http://lists.isc.org/> will sign are things that it 
generates itself (i.e. things from the lists.isc.org <http://lists.isc.org/> 
domain).

> 
> will my dkim fail aswell ?

Re: DKIM failure, both SPF and DKIM is well known to be broken by mailing 
lists.  So if you're running a dmarc-enforced domain with a policy of P=reject, 
it's possible that mail you send via a list will be rejected.

Altering the body or headers at all (whch lists do) will often break the 
hashing.  For this reason, most recent versions of mailman have an option to 
rewrite your mail from:

From: "Benny Pedersen" http://example.com/>>

...to...

From: "Benny Pedersen via bind-users" http://lists.isc.org/>>
Reply-To: "Benny Pederson" http://example.com/>>
Cc: bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>

...but only in the event you have a restrictive DMARC policy.  I've argued that 
it should be possible to do so for *any* dmarc policy, even p=none, but that 
option is not present in mailman 3, at least.

Here at ISC, we have a little bit of a cheat -- messages *we* send to 
bind-users will pass SPF, because lists.isc.org <http://lists.isc.org/> is in 
our SPF list.

The upcoming "better" solution for this is ARC: basically a way for 
lists.isc.org <http://lists.isc.org/> to assert "This thing passed muster when 
it entered our borders, trust us".

-Dan Mahoney

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



signature.asc
Description: Message signed with OpenPGP
___
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

One more test -- sorry for the noise

[Dan Mahoney]

Sorry for the noise, attempting to validate a DKIM issue
___
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

test -- please ignore

[Dan Mahoney]

testing, please ignore
___
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

lists.isc.org upgrade

[Dan Mahoney]

Greetings bind-users netizens.

Dan Mahoney here, ISC sysadmin/devops person.

We've upgraded the underlying server that lists.isc.org runs on, as well 
as an upgrade to mailman (still in the 2.x line).  This means any 
searchable archives will have to rebuild over the next day,

Please report any issues you spot to listmaster@ or bind-users-owner@

On a related note: A move to mailman3 is scheduled soon.  Mailman 2 is 
*everywhere* and only runs on an EOL'd version of python, and it's not 
*quite* compatible with mailman2's archives.  We're working with the 
mailman devs to fix a few issues before we make the jump.

Stay safe,

-Dan Mahoney
___
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

lists.isc.org upgrade (newer mailman, newer OS)

[Dan Mahoney]

Greetings bind-users netizens.

Dan Mahoney here, ISC sysadmin/devops person.

We've upgraded the underlying system that lists.isc.org runs on, as well
as an upgrade to mailman (still in the 2.x line).  This means any
searchable archives will have to rebuild over the next day.

Please report any issues you spot to listmas...@isc.org or 
bind-users-ow...@lists.isc.org

On a related note: A move to mailman3 is scheduled soon.  Mailman 2 is
=everywhere= and only runs on an EOL'd version of python, and it's not
*quite* compatible with mailman2's archives.  We're working with the
mailman devs to fix a few issues before we make the jump.

Stay safe,

-Dan Mahoney
___
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

Testing, please ignore

[Dan Mahoney]

testing, please ignore
___
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

lists.isc.org and DMARC

[Dan Mahoney]

Greetings bind-users netizens.

Dan Mahoney, ISC SysAdmin here.

This is a message about lists.isc.org and DMARC.  If you aren't concerned 
with DMARC, you can ignore it.  

Over a year ago, we added adaptations to lists.isc.org to allow mail from 
DMARC-protected domains to be delivered.

If you've seen problems with the way lists.isc.org currently handles DMARC 
(rewriting the From: header if your sending-domain has a restrictive 
[p=reject or p=quarantine] DMARC policy), we'd like to hear from you at 
listmas...@isc.org as we are considering making a slightly broader change.

We are considering setting lists.isc.org to ALSO rewrite the From: header, 
even if your sending-domain has a DMARC (p=none) policy.  We think this is 
important because otherwise a domain, in rolling out DMARC with p=none to 
start, will see false positives from mailing lists (indicating that 
messages sent via that list would be rejected by the final recipients' 
mailservers/filters).

We believe it makes sense for lists.isc.org to behave the same for *ANY* 
DMARC policy and are considering implementing that in the next few weeks.  
We will keep you updated here.

-Dan Mahoney
ISC
___
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

Testing

[Dan Mahoney]

Please ignore -- just testing post mailman upgrade.

Best,

-Dan Mahoney
ISC Operations Group
___
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

Test, please ignore

[Dan Mahoney]

Sorry for the noise
___
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

Testing SMTP

[Dan Mahoney]

Sorry for the noise, please ignore.

-Dan Mahoney
ISC Ops team
___
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

Testing

[Dan Mahoney]

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

One final test.

[Dan Mahoney]

Sorry again for the noise.

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

Testing, please ignore

[Dan Mahoney]

Sorry for the noise.

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

Testing, please ignore

[Dan Mahoney]

Sorry for the noise.

-Dan Mahoney
ISC
___
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: SPF records in reverse zones?

[Dan Mahoney]

On Thu, 6 Dec 2012, Karl Auer wrote:

> This may be a silly question, but are SPF records supposed to be
> supported in reverse zones? I'm thinking of a mail server that has no
> entry in the DNS.

Well, most mail servers will reject such a server (i.e. one with NO rdns).  
However, there's another possible interpretation of your request.

SPF records go in the zone of the envelope-sender.  So if your server's ip 
is 72.9.101.130, and your mail address REALLY is 
b...@130.101.9.72.in-addr.arpa, then the reverse zone would also need to 
have an MX and possibly an A record, in order to route mail to it, which 
goes a far cry from being "a server that has no entry in the DNS".

I can't even imagine what spamfilters would think of such an address. :)

-Dan Mahoney
___
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: DNS Blackholing

[Dan Mahoney]

On Dec 3, 2012, at 5:52 PM, rvandol...@esri.com wrote:

> All;
> 
> Am looking to do some DNS blackholing based on a pre-defined, dynamic list 
> (such as DNS-BH).  Am looking for feedback on approaches for this.
> 
> Sounds like automatically generating an includeable config file with zone 
> entries which point to a fairly bare zone definition file returning a 
> honeypot IP or some such thing is fairly commonly done.

Others may offer different advice, but while that was a common way to do it in 
the past, a feature in most modern versions of  BIND nowadays is Response 
Policy Zones.  Explaining them in full is beyond the scope of a simple mailing 
list post, but a good starting point is vixie's blog entry on the ISC website 
here: ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt

> We have several resolvers (caching) servers, and am curious how others out 
> there handle those.  Do you set up each as a master or do the master/slave 
> thing?  Presumably the former do avoid needless duplication of the bare zone 
> file.

See above.

> In addition, how much memory is used by BIND for each zone definition?  We 
> currently have a fairly small deployment with maybe a hundred zones tops.  If 
> we suddenly jump to 1+ -- even if they are all very small, how much 
> memory can we expect to be chewed up so we can plan ahead?

With RPZ, you have a single zone instead of 10,000.  It shows promise and much 
better scaling, as well as the ability to replicate your single policy zone via 
standard AXFR/IXFR metrics.  SpamHaus is currently making some of their data 
available in this format:

http://www.spamhaus.org/news/article/669/

-Dan Mahoney

___
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: Find all authoritative domains for a nameserver?

[Dan Mahoney]

> Hi all,
> 
> I don't know if there's an easy, or even moderately easy way to do
> this, but can one somehow figure out/get a list of all domains for
> which the nameserver is set to a given IP/server name? For reasons I
> won't get into, the people who register the domains are not the same
> as the people who run the DNS servers (me) and occasionally the
> domains I have zones defined for in my nameservers do not match the
> WHOIS records. Normally, that problem becomes pretty obvious because
> nothing works right, but it does generate a lot of logging for failed
> queries to the nameservers. I guess that would be one way to tell when
> someone has made us authoritative for a domain but not had us create a
> zone file, but is there a way to get a list somehow?

Back in the old netsol days, a name server admin could get a list of domains 
for which was responsible by request.  There's also a feature in very very old 
versions of bind called Inverse DNS, implemented against an optional part of 
one of the DNS spec, that comes close to this.  Nowadays, verisign and a few 
others WILL let you download the COM zone via FTP once a day, with special 
signed agreements (mainly for research purposes, not to solve your problem).

Your best answer comes in either your logs (with some simple grep and perl to 
do the dig +trace, could make a nice useful report), or some other tool like 
TCPDUMP, or in a passive DNS provider, but the reality is, all these methods 
require someone to be querying it.  Thankfully, spambots seem to do this quite 
a lot, and manage to find "new" domains at an alarming pace.

-Dan Mahoney
ISC
___
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: Duplicates in newsgroup gateway

[Dan Mahoney]

On Mon, 25 Jun 2012, David Ford wrote:

> it's posted 2x, slightly different.
> 
> To: comp.protocols.dns.b...@googlegroups.com
> To: comp-protocols-dns-b...@isc.org

I suspect this is an artifact of people starting a thread one place and 
cc'ing one reflector or the other.  I'll see if I can reach out to the 
googlegroups folks and figure a way to sort this.

-Dan

___
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

[META] Usenet/bind-users cross-posting is back

[Dan Mahoney]

All,

For much of the history of bind-users, there was a two-way crosslink 
between bind-users and usenet's comp.protocols.dns.bind.

This access went away when ISC transitioned to mailman for our mailing 
list management.  (At the same time, ISC was decomissioning its usenet 
server as well).

I'm happy to announce that as of today, with some help from Russ Alberry 
and the fine people at Stanford University, we've restored this 
functionality.

(Note: we are working on re-adding search functionality for all of ISC's 
mailing lists to the archives on our site -- the htdig patchset for 
mailman stopped working in a recent version of mailman and we have to 
re-integrate a different search engine).

Regards,

Dan Mahoney
ISC Operations Team
___
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

[META] Usenet cross-posting is back.

[Dan Mahoney]

All,

For much of the history of bind-users, there was a two-way crosslink
between bind-users and usenet's comp.protocols.dns.bind, a moderated 
usenet group.

This access went away when ISC transitioned to mailman for our mailing
list management.  (At the same time, ISC was decomissioning its usenet
server as well).

I'm happy to announce that as of today, with some help from Russ Alberry
and the fine people at Stanford University, we've restored this
functionality.

(Note: we are working on re-adding search functionality for all of ISC's
mailing lists to the archives on our site -- the htdig patchset for
mailman stopped working in a recent version of mailman and we have to
re-integrate a different search engine).

Regards,

Dan Mahoney
ISC Operations Team

___
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

Testing, please ignore

[Dan Mahoney]

Please ignore.  Internal test from ISC.

-Dan Mahoney
ISC Operations
___
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: Slow list

[Dan Mahoney]

On Tue, 5 Jul 2011, Chris Thompson wrote:

> On Jun 1 2011, Alan Clegg wrote:
> 
> > On 6/1/2011 7:16 AM, /dev/rob0 wrote:
> > > On Wed, Jun 01, 2011 at 09:54:04AM +0200, Jan-Piet Mens wrote:
> > > > > Does anyone else find the bind-users list to be very slow?
> [...]
> > I'll have operations take a look into what is causing the delay (it
> > doesn't happen on all mail to the list...)
> 
> Delays were very noticeable today for the bind-announce messages copied
> to bind-users. From the Received headers, the delay seems to happen
> between webster.isc.org and the next host: either mx.ams1.isc.org or
> mx.pao1.isc.org for different messages. In the worst case, there was
> delay of over 3 hours between webster receiving the message and passing
> it on.

We are working on this -- I believe we've discovered the problem 
internally, it seems to be a bad link between the handoff from mailman to 
postfix on a large list, exacerbated by several users whose domains return 
a SRVFAIL response.  (The irony here of course is that those users need 
the help the list could offer the most).

This seems to be because mailman asks postfix to do a "verify" (but not an 
SMTP VRFY) of the addresses as part of the VERP that it does.

One annoying thing that I should note is that removing those problem users 
and flushing the queues does NOT help.

-Dan

___
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: 9.8.0 in 2008 R2 x64 server

[Dan Mahoney]

On Tue, 5 Apr 2011, Jukka Pakkanen wrote:

> I'm moving one of our DNS servers (Win 2003 R2, v9.7.0) to a new 2008 R2 x64
> server.
> 
> After installing v9.8.0 I copied the /etc directory & subdirectories, the
> named user has full rights in relevant directories and "log on as a service"
> rights... still I get the following error in eventviewer when trying to start
> the service:
> 
> "none:0: open: C:\Windows\system32\dns\etc\named.conf: file not found"
> 
> Any ideas?  The named.conf file IS there, and the directories/datafiles are
> identical to our old, working server.  Tested with "administator" as the user
> as well, same problem.

Start a command shell as that user and try to more the file?

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

test

[Dan Mahoney]

test, please ignore

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