[1243] in Hesiod
Re: [Hesiod] Announce: Hesutils, the Hesiod utilities
daemon@ATHENA.MIT.EDU (JFLF)
Thu Feb 25 14:50:27 2021
To: Mitchell E Berger <mitchb@mit.edu>, Andy Bennett <andyjpb@ashurst.eu.org>
From: JFLF <jflf-gitlab@outlook.com>
Message-ID: <AM7PR04MB7096DA24C17C2947DC280410819E9@AM7PR04MB7096.eurprd04.prod.outlook.com>
Date: Thu, 25 Feb 2021 20:49:35 +0100
In-Reply-To: <alpine.LFD.2.20.2102251026340.1632@fez.xvm.mit.edu>
Content-Language: en-US
MIME-Version: 1.0
Cc: hesiod@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: hesiod-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Hello Mitch,
Thank you for your feedback! I queried your server from memory and I made a mistake, and that's why it didn't work. I've just checked again, properly this time, and it works indeed.
While someone from MIT is participating in the conversation, I'd have a few questions if you don't mind:
1) Currently ns.athena is wide open. If you know the record name, you get the data. I assume that this data is openly available in other ways, and thus Hesiod doesn't represent a major privacy risk for the MIT. Yet have you ever considered securing this zone in some way, and if so, which ways did you consider?
2) From your email I understand that you're moving away from Hesiod, is that correct?
Thank you very much!
JF
On 25/02/2021 16.32, Mitchell E Berger wrote:
> Though more and more stuff at MIT looks up some of the data in question in LDAP, Hesiod is still available and in use by some parts of Athena (and in particular by machines still running older versions of Athena). The ns.athena.mit.edu zone is still available; we just stopped using class HS and moved it all to class IN some years back.
>
> Mitch
>
> On Thu, 25 Feb 2021, Andy Bennett wrote:
>
>> Hi,
>>
>>>> It looks great.
>>>> I also have a script called `hesgen` that I wrote years ago but it's
>>>> nowhere near as sophisticated or well written as this one! ...
>>>
>>> Thank you for the kind words! I hope that you won't change your
>>> mind after looking into it more closely. :)
>>
>> It still looks great, although I noticed that he 2 example pages don't seem
>> to exist.
>>
>>
>>> I was going to add that the MIT still have their Hesiod NS
>>> (ns.athena.mit.edu) available over the internet without any
>>> security of any sort. That's the reason why there's an option to
>>> block requests to that NS in the Hesutils configuration file, as
>>> unconfigured clients would send their requests there. But it
>>> seems to have disappeared! I'm only getting a custom SOA with
>>> "HESREQ.mit.edu." as the rname.
>>>
>>> When I started writing those scripts, about 4 years ago, that
>>> NS still answered. So it seems that the changes have happened
>>> comparatively recently. Does anyone know what happened? Are they
>>> still using Hesiod internally, or have they decommissioned their
>>> Hesiod infrastructure entirely?
>>
>> I had noticed that the ns.athena.mit.edu zone was still available a few
>> years ago when I was thinking about GDPR stuff here in the UK.
>> I hadn't noticed that it had since disappeared tho'.
>> Good find!
>>
>>
>> It strikes me that Hesiod + Kerberos are a good design that haven't kept up
>> with advances in cryptography practice. ...and there are lots of projects
>> which are vainly attempting to do similar things over https, etc. They all
>> seem a lot more complex. It'd be nice if Hesiod & Kerberos were up-to-date
>> with security and crypto practices as they otherwise still seem to be
>> best-in-class approaches to the underlying problems.
>>
>>
>>
>>
>>
>>
>> Best wishes,
>> @ndy
>>
>> --
>> andyjpb@ashurst.eu.org
>> http://www.ashurst.eu.org/
>> 0x7EBA75FF
>>
>> _______________________________________________
>> Hesiod@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/hesiod
>>
_______________________________________________
Hesiod@mit.edu
http://mailman.mit.edu/mailman/listinfo/hesiod
