DNSSEC validating resolver on machines without RTC or wrong date

Fred Morris m3047-unbound-b3u at m3047.net
Wed Apr 19 23:24:25 UTC 2023


"Pulling yourself up by your bootstraps" is never going to be pretty, 
although it can be entertaining (I'm picturing Jerry Lewis or Dick Van 
Dyke on the Carol Burnett show).

On Wed, 19 Apr 2023, Petr Menšík via Unbound-users wrote:
> 
> If you add this into /etc/hosts, then you could instead just use fixed 
> address(es) in NTP service instead of a name. The use of DNS is good, because 
> you can change it on server only and clients will notice that soon.
>
> If you hardcode IP address or address for the name, then there is no reason 
> to use the name anymore. A comment above IP addresses would be just as good.

There are clearly options. 8)

> On 16. 04. 23 15:43, tito via Unbound-users wrote:
>>  On Sun, 16 Apr 2023 09:19:13 -0400
>>  James Cloos via Unbound-users <unbound-users at lists.nlnetlabs.nl> wrote:
>>
>>>>>>>>  "FMvU" == Fred Morris via Unbound-users
>>>>>>>>  <unbound-users at lists.nlnetlabs.nl> writes:
>>> FMvU>  This is where it starts to go off the rails for me. I mean: where?
>>> FMvU>  Someplace which is neither configured a fixed address or 
>>> FMvU>  provisioned
>>> FMvU>  with DHCP... and yet is connected to the internet: where is that?
>>>
>>>  he means a fixed ip for the ntp server, not for the client.
>>>
>>>  -JimC
>>  Hi,
>>  couldn't this be added to /etc/hosts?

DNSSEC requires accurate time (as does TSIG). Without going into the 
sprawling, messy details (they're everywhere!) it's because The DNS is a 
global resource.

DNS the protocol, operating locally in a controlled environment, arguably 
doesn't need DNSSEC at all. Today. Not yesterday. Today; and tomorrow. 
(Not sure about the day after that.)

Bootstrapping is a messy thing, and it often requires doing things at one 
stage which are countermanded / replaced / nullified at a later stage. 
Like that keyboard, or a disk, or network card, needing a driver loaded 
before the "real" boot.

In a containerized environment, /etc/hosts could indeed be edited in the 
image by the host OS prior to booting the image. OTOH it could certainly 
have an initial value which points to a local resource to start with. Lots 
of options here, some much more complicated or sophisticated (not 
interested in saying anything here is a "problem" thereby in need of a 
patented "solution").

I helped build a malware sandbox which ran malware which was most def 
interested in learning as much as possible about its operating 
environment. Needless to say, we were successful. We did it with 
adversarial payloads, and you (generic traditional rhetorical plural) 
can't do it when presented with an environment which is purpose built to 
help you succeed? I find it puzzling... at least, excepting misfeasance 
and malfeasance.

I still want to understand more about "what boot environment does this?" 
but this is not a DNS question. I totally get that a device could boot a 
real OS without having a real clock. Why can't someone propose a real 
environment as a reference model to center and pin this discussion?

--

Fred Morris


More information about the Unbound-users mailing list