@MSGID: 2:5075/21@fidonet 7d725da7
@REPLY: 2:5001/100@fidonet 6a9351d4
@CHRS: CP850 2
@TZUTC: 0200
@PID: SeenBy macOS MVP
@TID: SeenBy Tosser 0.1

Hello Dmitry, Eugene!

 I`ve been following this discussion, and perhaps I can step in here
as a third party.

 I may be missing some Fido-specific detail, of course (20 year of
absence, after all), but professionally I design systems for a living, so I
tend to look at this kind of question in terms of sources of truth,
dependencies, failure modes and graceful degradation rather than "DNS good/IP bad"
or vice versa.

And I think two different proposals are getting mixed together here.

DP> Adding dynamic IP addresses to the nodelist is the most stupid idea
DP> I`ve heard in a long time.

 I would agree that putting *dynamic* IP addresses into the nodelist
makes very little sense.

But that is not the only possible design.

 What if we allow a *static* IP to be specified as an optional
field, in addition to the hostname?

Something conceptually like:

    hostname = node.example.org
    static_ip = 192.0.2.42       ; optional

 If a sysop has no static IPv4 or IPv6 - nothing changes. The
field simply isn`t there. So the fact that an ISP in Moscow or London
doesn`t provide static IPv6 isn`t really a problem for this model.

 If the sysop does have a genuinely static address, however, the
nodelist may contain both pieces of information.

 And we`re hardly constrained by line length here: a nodelist line
may be up to 1024 characters. We have enough room for a hostname and
an optional IPv4/IPv6 address without having to remove the sysop`s
surname to make it fit. :)

 From a system architecture point of view, I see the trade-off
approximately like this:

    Strengths:
    - two independent ways to reach a node;
    - graceful degradation when DNS fails;
    - nodelist remains the single source of truth;
    - DDN can still be generated entirely from the nodelist;
    - completely backward-compatible for nodes which don`t use it.

    Weaknesses:
    - the fallback IP can become stale;
    - clients/generators need clearly defined fallback semantics;
    - one more optional piece of data has to be maintained.

    Opportunities:
    - mailers/DDN generators can automatically recover from a broken
      or stale DNS record instead of requiring manual configuration;
    - a complete DDN zone can be destroyed and regenerated from the
      nodelist without losing published endpoint information.

    Threats:
    - implementations may incorrectly treat the IP as more authoritative
      than the hostname;
    - stale IPs could cause connection attempts to the wrong endpoint
      unless the fallback rules are specified properly.

 To me, that looks like a fairly normal engineering trade-off rather
than a particularly crazy idea.

The semantics could be deliberately boring:

    resolve hostname
        |
        +-- connect succeeds --> done
        |
        +-- connection fails --> try optional static IP

This preserves the primary advantage of DNS.

 Suppose my IP changes today. I update DNS immediately and don`t
have to wait for the next nodelist. The old IP in the nodelist may
remain stale for a while, but it is only a fallback.

 Now consider the opposite failure, which apparently happened recently
with 2:5030/0.

 The IP did *not* change. The node remained reachable at that
address. What became stale was DNS. People eventually had to put the known
working IP into their mailer configurations manually.

 From an architecture point of view, that`s an interesting failure:
the endpoint was alive and its address was known, but one failed
dependency made it unreachable through the normal discovery mechanism.

Optional static IP solves precisely that failure mode.

There is another reason why I find this model attractive.

 As I understand the original DDN idea, DNS does not have to be an
independent source of information at all. Any node can take the nodelist, run
a parser over it and generate a named-compatible DNS zone. Such
scripts have existed before, AFAIK.

So conceptually:

    NODELIST
       |
       +------> nodelist-aware mailer
       |
       +------> DDN generator ------> DNS ------> DNS-only mailer

 I like this property because I can delete the generated DNS zone
completely, rebuild it from the nodelist, and lose nothing.

There is still exactly one authoritative dataset.

 This is also why I see a conceptual difference between that model
and services such as binkp.net if they contain records which are not
present in the nodelist. Such a service can certainly be useful - perhaps
even more useful operationally - but it is no longer merely a DNS
representation of the nodelist. It becomes another database containing knowledge
about the network.

 And then, wearing my architect hat, I immediately have to ask the
boring question architects always ask:

    If they disagree, which one wins?

DP> Have you ever tried to read data from
DP> https://nodelist.fidonet.cc/?

 This is actually why I think the question of authority matters more
than the particular representation.

 If the nodelist is the source of truth, everything else can be
generated, cached, indexed or presented however we like.

 If DNS or some web database is allowed to contain newer
authoritative endpoint information which is absent from the nodelist, that`s also
a perfectly possible architecture - but then we have multiple sources
of truth and need synchronization and conflict-resolution rules.

 Personally, for a distributed network whose nodes are maintained by
volunteers, I would rather have one authoritative dataset plus redundant ways of
reaching an endpoint than two authoritative datasets and a discussion about
which one is currently more correct.

So I don`t see this as "DNS versus IP" at all.

I see it as:

    hostname        - agility
    optional IP     - fallback
    nodelist        - authority

The cost is one optional field and a defined fallback rule.

The benefit is graceful degradation when one of the mechanisms fails.

 And given the nature and history of FidoNet, "the sysop disappeared
and didn`t update his DNS for a while, being stuck in alchogol trip"
seems to me less like an exotic corner case and more likely something
that should probably be somewhere in the threat model by design. :)

--- SeenBy 0.1
 * Origin: SeenBy macOS MVP (2:5075/21@fidonet)
SEEN-BY: 221/0 280/464 5003 5555 301/1 310/31
335/364 341/66 5001/100 5015/46
SEEN-BY: 5019/40 5020/715 1042 1146 4441 5030/1081
5051/44 5053/58 5075/21 35
@PATH: 5075/21 35 280/5555 5053/58 5020/715