Hello Eugene!

In a message of 30 Aug 26 02:10, Eugene wrote to Dmitry:

If you're planning

Which mailers? Give me names.

binkd, qico

1. binkd uses nodelist.pl for that, I've done it for years
2. for qico I've just generated subst file, easy peasy with awk

zero problems. And qico has hardcoded binkp.net domain anyway, which has tons of it's own issues.

You are trying to fix a problem which doesn't exists.

Follow the standards.

When 2:5030/0 had connectivity issues (which weren't uncommon), the IP address in the nodelist didn't help at all.

So all this debate about some "redundancy" is based literally on an illusory picture, not on real-life facts.

See you,
dp.
--- FidoMail v0.1.3-71-gfb9bc36
* Origin: livin' on the edge (2:5001/100)

Hello Eugene!

In a message of 30 Aug 26 02:11, Eugene wrote to Dmitry:

It makes no sense. Just check nodelist.fidonet.cc for stats, use
claude, if you are very busy with something else.

I don't want to.

Then you'll just continue living in a delusional fictional world.

Everyone can, like somebody who handles the binkp.net or any other
domain.
All domains are privately owned, and no one is protected against

That's why any single domain based solution for the whole network is bad.

the possibility that any of them might expire or contain incorrect
data that does not match the nodelist. But there is no requirement
to use a specific domain for DDN.

Or just use nodelist. End of story.

See you,
dp.
--- FidoMail v0.1.3-71-gfb9bc36
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Sunday August 30 2026 08:24, you wrote to me:

2. for qico I've just generated subst file, easy peasy with awk

The qico distribution does not include a single tool that allows a nodelist to be used as a data source for determining node addresses, even though it is capable of working with nodelists.

Follow the standards.

When 2:5030/0 had connectivity issues (which weren't uncommon), the IP address in the nodelist didn't help at all.

That's incorrect. The problem was specifically with resolving the name from the DNS; the node remained accessible via its IP address.

So all this debate about some "redundancy" is based literally on an illusory picture, not on real-life facts.

I wasn't starting any debate here. I just pointed out that there's no problem adding a static IP address to the nodelist.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260829 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

In a message of 30 Aug 26 11:30, Eugene wrote to Dmitry:

The qico distribution does not include a single tool that allows a

So binkd has everything to work with nodelist and your statement was fake news?

nodelist to be used as a data source for determining node
addresses, even though it is capable of working with nodelists.

Which qico fork? There are several of them, I even had my own.

That's incorrect. The problem was specifically with resolving the
name from the DNS; the node remained accessible via its IP address.

You can check outages for that node - they were global for both hostname and IP address.

So all this debate about some "redundancy" is based literally on
an illusory picture, not on real-life facts.

I wasn't starting any debate here. I just pointed out that there's
no problem adding a static IP address to the nodelist.

And the amazing news I wanted to present to you at the end: fidonet.net and binkp.net return different results for multiple nodes!

It means there are already different sources of truth! Which one is more authoritative?

It's just wonderful that by trying to solve a non-existent problem, you guys created another one - two non-matching DNS-based systems.

See you,
dp.
--- FidoMail v0.1.3-71-gfb9bc36
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Sunday August 30 2026 09:34, you wrote to me:

nodelist to be used as a data source for determining node
addresses, even though it is capable of working with nodelists.

Which qico fork? There are several of them, I even had my own.

https://sourceforge.net/projects/qico/

That's incorrect. The problem was specifically with resolving the
name from the DNS; the node remained accessible via its IP
address.

You can check outages for that node - they were global for both
hostname and IP address.

Incorrect. There were reports that when people entered a static IP address in their configuration files, connectivity was restored. The cause was precisely a malfunctioning DNS.

And the amazing news I wanted to present to you at the end:
fidonet.net and binkp.net return different results for multiple nodes!

It means there are already different sources of truth! Which one is
more authoritative?

That makes sense. You should have compared the ddn.binkp.net and fidonet.net zones.
Are there any discrepancies between them?

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260830 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

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.

Adding dynamic IP addresses to the nodelist is the most stupid idea
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?

Have you ever tried to read data from
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)

Hello Eugene!

In a message of 30 Aug 26 12:35, Eugene wrote to Dmitry:

Hello Dmitry!

Sunday August 30 2026 09:34, you wrote to me:

nodelist to be used as a data source for determining node
addresses, even though it is capable of working with nodelists.

Which qico fork? There are several of them, I even had my own.

https://sourceforge.net/projects/qico/

https://pastebin.com/Uk8s8LF9

And it even fixes qico's ipv6 related problems, by disabling ipv6 addresses.

Problem solved.

Incorrect. There were reports that when people entered a static IP
address in their configuration files, connectivity was restored.
The cause was precisely a malfunctioning DNS.

Last outage was on 2026-08-28 02:02:23 UTC - unreachable by both hostname and IP address.
And it makes no sense to use unreliable DNS at all. So instead of fixing the real problem, SysOp decided to ignore it.

Are there any discrepancies between them?

Yes, exactly.

End of story for me here.

See you,
dp.
--- FidoMail v0.1.3-71-gfb9bc36
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

In a message of 30 Aug 26 12:39, Dmitry wrote to Dmitry:

Have you ever tried to read data from
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.

Thank you for spending your time explaining your opinion in great detail!!

The problem is that fixing an untuned piano on a sinking Titanic is a very important task, yet it's not the most urgent and probably only a piano tuner is interested in it.

Let me explain current nodelist state and it's recent history:

we have 964 hostnames, 60 IP addresses and 4 entries had previously changed IP to hostname or vice versa and 11 nodes had both hostname and IP address.

Out of those 11 nodes only "s0t.ru" has problems with DNS resolution during the last 10 months. 10 nodes had no issues at all, IP address was not needed.

So the proposed solution (IP + hostname) could potentially save only one SysOp.

And if his DNS infrastructure is so fragile, he could do the most obvious fix - add a second hostname on any DDNS service available from Russia with low TTL. And it's not uncommon - 11 nodes have multiple hostnames, some from DDNS services.


As for real problems we need to solve:

135 hostnames in nodelist represent nodes that can't be accessed for more than 10 months, 45 of them never resolved to anything. No one is fixing them,

75 nodes have IP addresses, 20 of them never answered in the last 10 months.

This is what we should care about - the nodelist has _incorrect_information_, it's full of nodes with no connectivity at all (PSTN situation is another sad story).

By creating DNS based services based on false information people just increase chaos, they are fixing problems which have no influence over the whole picture.

What I see as a potential project - is to create a nodelist and if someone wants - a DNS service which will contain real, proven information. Only nodes which could be reached! Even potentially.

Because it makes zero (!) sense to try to connect to a node that's been dead for years via an IP address obtained from binkp.net or fidonet.net. It's just a waste of time and human resources debugging potential connection issues for every SysOp who doesn't realize the node is long dead.



See you,
dp.
--- FidoMail v0.1.3-71-gfb9bc36
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry Protasoff!

Hello Dmitry!

Thank you - and actually, I mostly agree with your diagnosis.

If these statistics are representative, then yes: stale and completely dead entries in the nodelist are a much bigger operational problem than DNS failures.

But I think we've just changed the subject. :)

What we were discussing was a very small and rather deterministic change:

hostname
optional static IP

with equally boring semantics:

try hostname
if it fails -> try static IP, if present

That's a small feature, cheap to implement, backward-compatible, and it addresses one specific failure mode.

What you are proposing now is much more interesting - but also a completely different class of problem.

What I see as a potential project - is to create a nodelist and if
someone wants - a DNS service which will contain real, proven
information. Only nodes which could be reached! Even potentially.

Now *this* makes my architect alarm start making noises. :)

Because "real, proven information" and "could be reached" sound simple until we try to specify them.

What exactly constitutes proof that a node is dead?

One failed TCP connection?
Ten?
For an hour?
A day?
A month?

From one probe?
From several networks?
Several countries/ASes?

What about a node which is reachable only at certain times?

What about:

DNS fails, IP works
DNS works, TCP fails
IPv4 works, IPv6 fails
IPv6 works, IPv4 fails
one probe reaches it, another doesn't
connection succeeds but there is no valid BinkP response
what about sysops not involved in mail tranfer? For example, I just returned, so Fido was working without me somehow, I don't have intetion on giving a point to anyone (and I don't see a queue for the either), so I will not respond. How about that?

And most importantly: who is allowed to turn an observation made by an automated monitoring system into authoritative information about FidoNet topology?

That's not an argument against the idea. Quite the opposite - I think it's a much more interesting and probably much more useful project.

But compared to adding one optional field, this has considerably more architectural uncertainty. We have suddenly gone from:

"store another endpoint"

to:

"design a distributed node health/validation system and define
how its observations affect authoritative network state."

Those are rather different-sized jobs. :)

And curiously, the first proposal doesn't interfere with the second one at all.

It actually gives the second one a useful tool.

Suppose the nodelist says:

hostname = node.example.org
static_ip = 192.0.2.42

Your validator tries the hostname and fails.

Without the second endpoint, all it knows is:

node unreachable through hostname

With the optional static IP it can independently try:

192.0.2.42

and now it can distinguish at least two very different conditions:

hostname fails + IP fails
-> probably an endpoint/node/connectivity problem

hostname fails + IP works
-> node is alive, DNS path is broken

That's rather valuable information for exactly the project you're proposing.

So the proposed solution (IP + hostname) could potentially save only
one SysOp.

Yes. Based on your ten-month sample, apparently one SysOp.

That's useful information and it certainly changes the *priority* I would assign to the feature.

But it doesn't really change its cost or architecture.

We are talking about an optional field in a format where a line may be up to 1024 characters, plus a trivial fallback rule. Nodes without static addresses don't use it. Existing software can ignore it. Nothing needs a new central service.

So I wouldn't stop fixing the Titanic's hull in order to tune the piano. :)

But if the piano tuner needs thirty seconds and his work doesn't interfere with the people fixing the hull, I'm not sure we need to throw his wrench overboard either.

And your proposal about cleaning the nodelist is definitely the hull problem.

I'd be much more interested now in discussing how to define "dead node" reliably enough that the resulting information can be trusted.

Because I think that is where the genuinely difficult architecture begins.

And, conveniently, having more than one independently testable endpoint in the authoritative nodelist would make that job easier, not harder.


--- SeenBy 0.1
* Origin: SeenBy macOS MVP (2:5075/21@fidonet)

Hi All,

New node in net 104: ,121,L33Test,Denver_CO,Matthew_Hansen,-Unpublished-,300,CM,INA:bbs.l33test.com,IBN
Connect with BinktermPHP/1.10.3, but getting this response: "Got binkp error: Authentication failed."
Node doesn't need to be in the nodelist if it doesn't accept crash mail.

Host 2:5030/0 and aka's /137 /1000 and /731 got INA:217.71.231.2 added. This is the same IP as the other INA:f731.s0t.ru resolves to, so why is this needed? Is the dns system for .ru unreliable?

Pvt node 2:5033/21 got the CM flag removed, but still lists an IBN and INA flag. I get an error: 'No route to host' when trying to connect there. Maybe I should try during ZMH...?

Node 3:633/414 went from Down to Pvt, and all flags after the baudrate were correctly removed.


Bye, Wilfred.

--- FMail-lnx64 2.3.4.1-B20260520
* Origin: NPC station (2:280/464)

Hello Wilfred!

Friday August 28 2026 12:09, you wrote to All:

Host 2:5030/0 and aka's /137 /1000 and /731 got INA:217.71.231.2
added. This is the same IP as the other INA:f731.s0t.ru resolves to,
so why is this needed? Is the dns system for .ru unreliable?

This is acceptable, and they also serve as backups for each other. If the IP address changes, the DNS record can be quickly updated. And if the DNS record becomes unavailable for any reason, there is still a backup. As a result, the DNS Distributed Node List generates the following records:

f0.n5030.z2.fidonet.net. 3600 IN A 217.71.231.2 _binkp._tcp.f0.n5030.z2.fidonet.net. 3600 IN SRV 0 1 24554 f0.s0t.ru. _binkp._tcp.f0.n5030.z2.fidonet.net. 3600 IN SRV 0 1 24554 f0.n5030.z2.fidonet.net.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hi Eugene,

On 2026-08-29 10:33:06, you wrote to me:

Host 2:5030/0 and aka's /137 /1000 and /731 got INA:217.71.231.2
added. This is the same IP as the other INA:f731.s0t.ru resolves to,
so why is this needed? Is the dns system for .ru unreliable?

This is acceptable, and they also serve as backups for each other. If the IP
address changes, the DNS record can be quickly updated. And if the DNS record
becomes unavailable for any reason, there is still a backup.

How "often" does that happen? Almost never. I think adding the IP number as extra INA, is unnecessary bloat in the nodelist.

What if all nodes did this? Even the nodes with IPv6 addresses?

Bye, Wilfred.

--- FMail-lnx64 2.3.4.1-B20260520
* Origin: NPC Station (2:280/464)

Hello Wilfred!

In a message of 29 Aug 26 11:50, Wilfred wrote to Eugene:

How "often" does that happen? Almost never. I think adding the IP
number as extra INA, is unnecessary bloat in the nodelist.

Russian internet is very unreliable, and Russian DNS is also unreliable (requests to google/cloudflare 8.8.8.8 and 1.1.1.1 are being filtered or altered (!)), but this cannot be fixed by adding tons of extra information into the nodelist, for sure.

Connections to my node 2:5001/100 with binkp protocol drop because of internet censorship in Russia, but connections from my node are ok.

So a russian SysOp should care only about his outgoing connections (like connecting to my node, hosted in the UK), incoming connections to his node from other nodes inside and outside Russia will be ok - no need to duplicate anything.

What if all nodes did this? Even the nodes with IPv6 addresses?

Exactly!

See you,
dp.
--- FidoMail v0.1.3-51-g01f3c4c
* Origin: livin' on the edge (2:5001/100)

Hello Wilfred!

Saturday August 29 2026 11:50, you wrote to me:

This is acceptable, and they also serve as backups for each
other. If the IP address changes, the DNS record can be quickly
updated. And if the DNS record becomes unavailable for any
reason, there is still a backup.

How "often" does that happen? Almost never. I think adding the IP
number as extra INA, is unnecessary bloat in the nodelist.

In this case, as far as I know, the sysop was having trouble updating the DNS record on this host, and it was faster to make the changes in the nodelist, after which the records on binkp.net and fidonet.net were automatically regenerated. Connectivity was restored.

What if all nodes did this? Even the nodes with IPv6 addresses?

I don't see any problems with this at all :) And if all nodes do this, there will be far fewer issues with expired domain names in the node list and stale DNS records. Moreover, FTS-5004 specifically calls for this method of populating the DDN, and a CNAME pointing to an existing name is simply an alternative.


Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

In a message of 29 Aug 26 13:09, Eugene wrote to Wilfred:

I don't see any problems with this at all :) And if all nodes do

A lot of nodes have dynamic IP addresses; please stop breaking the working network with your crazy ideas.

this, there will be far fewer issues with expired domain names in

I have about 10 different IP addresses (ipv4/ipv6 combined) for 2:5001/100 working simultaneously. They are all covered by a single hostname: f100.5001.ru.

Some of them are being added, some being removed automatically. Do you want me to also update the nodelist each time? Twice per day?

Please stop breaking the working network with your crazy ideas - you don't fully understand how FidoNet is working right now, not in your dreams.


See you,
dp.
--- FidoMail v0.1.3-69-g504ee66
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Saturday August 29 2026 19:34, you wrote to me:

I have about 10 different IP addresses (ipv4/ipv6 combined) for
2:5001/100 working simultaneously. They are all covered by a single hostname: f100.5001.ru.

Some of them are being added, some being removed automatically. Do you want me to also update the nodelist each time? Twice per day?

Please stop breaking the working network with your crazy ideas - you
don't fully understand how FidoNet is working right now, not in your dreams.

Please read the FTS-0004.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Dmitry!

Sunday August 30 2026 00:23, I wrote to you:

Please stop breaking the working network with your crazy ideas -
you don't fully understand how FidoNet is working right now, not
in your
dreams.

Please read the FTS-0004.

FTS-5004 of course. This is a method for static IP addresses. No one has ever required it to be used for dynamic ones.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

In a message of 30 Aug 26 00:23, Eugene wrote to Dmitry:

Please stop breaking the working network with your crazy ideas -
you don't fully understand how FidoNet is working right now, not
in your dreams.

Please read the FTS-0004.

Again: you don't fully understand how FidoNet is working right now.

Adding dynamic IP addresses to the nodelist is the most stupid idea I've heard in a long time. And I have *zero* available internet providers with static IPv6 both in Moscow and London in my apartments.

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

See you,
dp.
--- FidoMail v0.1.3-69-g504ee66
* Origin: livin' on the edge (2:5001/100)

Hello Eugene!

In a message of 30 Aug 26 00:36, Eugene wrote to Dmitry:

Please read the FTS-0004.

FTS-5004 of course.

In addition to FTS-0004? Please read your posts before pressing "send" button or whatever you are using.

This is a method for static IP addresses. No

There is nothing about putting IP addresses into the nodelist in it.

one has ever required it to be used for dynamic ones.

FTS-5004 is an example of why centralized DNS system should not be used for FidoNet - tomorrow Putin will send the fidonet.net owner to war, he'll be killed and everyone will have to go via the same route again (and next time it could take even more years to restore this service).

See you,
dp.
--- FidoMail v0.1.3-69-g504ee66
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Saturday August 29 2026 21:40, you wrote to me:

Please read the FTS-0004.

Again: you don't fully understand how FidoNet is working right now.

Adding dynamic IP addresses to the nodelist is the most stupid idea
I've heard in a long time. And I have *zero* available internet
providers with static IPv6 both in Moscow and London in my apartments.

So don't add the dynamic ones - no one's forcing you to. In this case, a CNAME record will be generated.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Dmitry!

Saturday August 29 2026 21:54, you wrote to me:

This is a method for static IP addresses. No

There is nothing about putting IP addresses into the nodelist in it.

See the example #2 and #5 in it.

one has ever required it to be used for dynamic ones.

FTS-5004 is an example of why centralized DNS system should not be
used for FidoNet - tomorrow Putin will send the fidonet.net owner to
war, he'll be killed and everyone will have to go via the same route
again (and next time it could take even more years to restore this service).

The DDN domain can be absolutely anything. Nothing is stopping you from creating a zone on your own domain.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

In a message of 30 Aug 26 00:54, Eugene wrote to Dmitry:

So don't add the dynamic ones - no one's forcing you to. In this

So you idea of all nodes adding their IP addresses was wrong?

---

What if all nodes did this? Even the nodes with IPv6 addresses?

I don't see any problems with this at all :)
---

And I see a lot of problems even with my own node. FidoMail fully supports CDN and I am using it for connectivity in Russia and now also in Asia. There is zero sense to add IP addresses of region-specific CDN nodes into nodelist!



See you,
dp.
--- FidoMail v0.1.3-69-g504ee66
* Origin: livin' on the edge (2:5001/100)

Hello Eugene!

In a message of 30 Aug 26 00:58, Eugene wrote to Dmitry:

See the example #2 and #5 in it.

And what should I see there? Are you busy with something and just don't have time to explain?

The DDN domain can be absolutely anything. Nothing is stopping you
from creating a zone on your own domain.

What for? If I have a nodelist, I don't need any DNS-based solution to reach other nodes.

And you can reach 2:5001/100 by its hostname from China or Russia without using any FTS-5004 solution, bypassing state owned DPI restrictions. Adding an IP address will ruin it.


See you,
dp.
--- FidoMail v0.1.3-69-g504ee66
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Saturday August 29 2026 22:06, you wrote to me:

So don't add the dynamic ones - no one's forcing you to. In this

So you idea of all nodes adding their IP addresses was wrong?

It wasn't my idea.

And I see a lot of problems even with my own node. FidoMail fully
supports CDN and I am using it for connectivity in Russia and now also
in Asia. There is zero sense to add IP addresses of region-specific
CDN nodes into nodelist!

So use the DNS name. After all, this only applied to nodes with static IP addresses. I really don't see a problem with including those IP addresses in the nodelist.

As this case has shown, DNS names can be lost or become unavailable, while the IP address remains accessible. In such cases, it makes sense to include both entries in the nodelist.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

In a message of 30 Aug 26 01:17, Eugene wrote to Dmitry:

It wasn't my idea.

So you are against that and now you see the problems with that?

And I see a lot of problems even with my own node. FidoMail fully
supports CDN and I am using it for connectivity in Russia and now
also in Asia. There is zero sense to add IP addresses of
region-specific CDN nodes into nodelist!

So use the DNS name. After all, this only applied to nodes with
static IP addresses. I really don't see a problem with including
those IP addresses in the nodelist.

What for? Fixing DNS name is much faster than fixing entry in nodelist.
Do you know how many nodes actually use the current nodelist?

As this case has shown, DNS names can be lost or become

IP address could be lost even more easily. Do you know how many IP addresses from nodelist are actually working?

Did you check https://nodelist.fidonet.cc/ ?


See you,
dp.
--- FidoMail v0.1.3-69-g504ee66
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Saturday August 29 2026 22:20, you wrote to me:

See the example #2 and #5 in it.

And what should I see there? Are you busy with something and just
don't have time to explain?

There, you can see the IP addresses listed in INA/IBN, and how they will be used in DDN.

The DDN domain can be absolutely anything. Nothing is stopping
you from creating a zone on your own domain.

What for? If I have a nodelist, I don't need any DNS-based solution to reach other nodes.

Some mailers cannot handle the text nodelist, only DNS-based.

And you can reach 2:5001/100 by its hostname from China or Russia
without using any FTS-5004 solution, bypassing state owned DPI restrictions. Adding an IP address will ruin it.

Don't add them.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

In a message of 30 Aug 26 01:30, Eugene wrote to Dmitry:

There, you can see the IP addresses listed in INA/IBN, and how they
will be used in DDN.

How it will help in my case?

Some mailers cannot handle the text nodelist, only DNS-based.

Which mailers? I can give you a solution to use any binkp mailer with text nodelist.
Just ask, don't be shy.

I've tested most of them (if not all).

And you can reach 2:5001/100 by its hostname from China or Russia
without using any FTS-5004 solution, bypassing state owned DPI
restrictions. Adding an IP address will ruin it.

Don't add them.

So adding 6 ipv6 addresses into nodelist is not a good idea? Did you check how current software treats nodelists with very long lines?

See you,
dp.
--- FidoMail v0.1.3-69-g504ee66
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Saturday August 29 2026 22:29, you wrote to me:

It wasn't my idea.

So you are against that and now you see the problems with that?

No, I'm not against.

What for? Fixing DNS name is much faster than fixing entry in
nodelist. Do you know how many nodes actually use the current
nodelist?

Not always. As we can see, there are cases where access to DNS name management is lost, or the DNS domain expires.
To ensure data is up to date, you need to use the up to date DDN, as it contains all the current information from the latest nodelist.
And anyone can set up a DDN like this on their own.

What's more, it doesn't matter at all whether the nodelist uses IP addresses or DNS names: both must be up to date.
However, in the event of problems with the DNS name, this method allows the node to remain accessible from the outside if it uses a static IP address.

Did you check https://nodelist.fidonet.cc/ ?

I didn't.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Dmitry!

Saturday August 29 2026 22:40, you wrote to me:

Which mailers? I can give you a solution to use any binkp mailer with
text nodelist. Just ask, don't be shy.
I've tested most of them (if not all).

If you're planning to convert the nodlist format to the mailer's configuration file format, that doesn't necessarily mean the mailer itself supports it. Besides, that still won't fix any stale or expired DNS records.

So adding 6 ipv6 addresses into nodelist is not a good idea? Did you
check how current software treats nodelists with very long lines?

For compatibility with certain broken segment processors, nodelist
maintainers should limit all lines to at most 157 characters (plus
terminator). It is very likely this limitation will be removed in
the future, therefore future software implementations should be able
to process lines of up to 1024 characters, and individual fields of
up to 255 characters (unless otherwise specified).


Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

In a message of 30 Aug 26 01:34, Eugene wrote to Dmitry:

Not always. As we can see, there are cases where access to DNS name management is lost, or the DNS domain expires.

Static IP addresses also expire even quicker.

To ensure data is up to date, you need to use the up to date DDN,
as it contains all the current information from the latest
nodelist.

I prefer to use nodelist because it's from our ZC. Fidonet.net, on the other hand, is owned by some anonymous motherfucker who could pass all connections through his MITM proxy, collecting passwords.

And anyone can set up a DDN like this on their own.

What for?

What's more, it doesn't matter at all whether the nodelist uses IP addresses or DNS names: both must be up to date.

It's much easier to keep IP addresses up to date via DNS. Nodelist updates take time. And people are lazy - some NCs don't update their segment for many months.

Did you check https://nodelist.fidonet.cc/ ?

I didn't.

So you don't have any statistics about the problems of current DNS and IP addresses? So sad.

See you,
dp.
--- FidoMail v0.1.3-69-g504ee66
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Saturday August 29 2026 22:56, you wrote to me:

Not always. As we can see, there are cases where access to DNS
name management is lost, or the DNS domain expires.

Static IP addresses also expire even quicker.

That is precisely why a dual entry, as in this case, is appropriate.

What's more, it doesn't matter at all whether the nodelist uses
IP addresses or DNS names: both must be up to date.

It's much easier to keep IP addresses up to date via DNS. Nodelist
updates take time. And people are lazy - some NCs don't update their segment for many months.

This is true only if you have access to manage this DNS record and the domain has not expired.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene!

In a message of 30 Aug 26 01:43, Eugene wrote to Dmitry:

Which mailers? I can give you a solution to use any binkp mailer
with text nodelist. Just ask, don't be shy.
I've tested most of them (if not all).

If you're planning

Which mailers? Give me names.

For compatibility with certain broken segment processors, nodelist maintainers should limit all lines to at most 157 characters (plus

Oops :) So I can't put my full node details into the nodelist. So sad!

You are trying to fix a problem which doesn't exists.

See you,
dp.
--- FidoMail v0.1.3-71-gfb9bc36
* Origin: livin' on the edge (2:5001/100)

Hello Eugene!

In a message of 30 Aug 26 01:59, Eugene wrote to Dmitry:

That is precisely why a dual entry, as in this case, is
appropriate.

It makes no sense. Just check nodelist.fidonet.cc for stats, use claude, if you are very busy with something else.

It's much easier to keep IP addresses up to date via DNS. Nodelist
updates take time. And people are lazy - some NCs don't update
their segment for many months.

This is true only if you have access to manage this DNS record and
the domain has not expired.

So you agree that an anonymous motherfucker with fidonet.net could break everything after a dose of heroin? And it makes no sense to use such DNS-based systems at all?

Just use nodelist, KISS.

See you,
dp.
--- FidoMail v0.1.3-71-gfb9bc36
* Origin: livin' on the edge (2:5001/100)

Hello Dmitry!

Saturday August 29 2026 23:03, you wrote to me:

If you're planning

Which mailers? Give me names.

binkd, qico

For compatibility with certain broken segment processors,
nodelist maintainers should limit all lines to at most 157
characters (plus

Oops :) So I can't put my full node details into the nodelist. So sad!
You are trying to fix a problem which doesn't exists.

Follow the standards.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Dmitry!

Saturday August 29 2026 23:06, you wrote to me:

It makes no sense. Just check nodelist.fidonet.cc for stats, use
claude, if you are very busy with something else.

I don't want to.

This is true only if you have access to manage this DNS record
and the domain has not expired.

So you agree that an anonymous motherfucker with fidonet.net could
break everything after a dose of heroin? And it makes no sense to use
such DNS-based systems at all?

Everyone can, like somebody who handles the binkp.net or any other domain.
All domains are privately owned, and no one is protected against the possibility that any of them might expire or contain incorrect data that does not match the nodelist. But there is no requirement to use a specific domain for DDN.

Eugene

... It's full of stars!
--- GoldED+/BSD 1.1.5-b20260828 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Dmitry!

In a message of 30 Aug 26 21:40, Dmitry wrote to Dmitry:

hostname
optional static IP

But why not use a second hostname?

The problem with the current nodelist is that NC/RC aren't updating them properly.

Adding an IP address there means changing it could take months! And changing the IP address of a hostname takes like 15 minutes with a glass of beer/wine.

Because "real, proven information" and "could be reached" sound
simple until we try to specify them.

What exactly constitutes proof that a node is dead?

One failed TCP connection?
Ten?
For an hour?
A day?
A month?

I already have statistics for 1 year for each node in nodelist.

DNS fails, IP works
DNS works, TCP fails
IPv4 works, IPv6 fails
IPv6 works, IPv4 fails

I have all those cases covered and much more.

so Fido was working without me somehow, I don't have intetion on
giving a point to anyone (and I don't see a queue for the either),
so I will not respond. How about that?

If you announce something in nodelist - you have to fulfill your promises.

And most importantly: who is allowed to turn an observation made by
an automated monitoring system into authoritative information about FidoNet topology?

It's completely optional. Just for people who don't have time to troubleshoot failed connections.

hostname = node.example.org
static_ip = 192.0.2.42

Your validator tries the hostname and fails.

I am testing everything: hostnames, IP addresses, all protocols, I check domains with whois, etc.

We are talking about an optional field in a format where a line may
be up to 1024 characters, plus a trivial fallback rule. Nodes

Not really 1024: 157 for several nodelist related utilities.
255 for ifmail. 512 for qico.

And your proposal about cleaning the nodelist is definitely the
hull problem.

We don't need zombies, we need people. Right now at least 1/3 of nodelist is a cemetery. Not even a museum.

I'd be much more interested now in discussing how to define "dead
node" reliably enough that the resulting information can be
trusted.

Check nodelist.fidonet.cc (or nodelist.5001.ru from Russia).


See you,
dp.
--- FidoMail v0.1.3-71-gfb9bc36
* Origin: livin' on the edge (2:5001/100)