Text 12948, 87 rader
Skriven 2022-09-16 22:34:15 av Oli (2:280/464.47)
  Kommentar till text 12945 av Pavel Gulchouck (2:463/68)
Ärende: FTS-5004
================
Hello Pavel!

Pavel wrote (2022-09-16):

 PG> Hi Oli!

 Ol>> I'm not sure ic.ddn would count as a DDN record, because it's not
 Ol>> in the f*.n*.z*.ddn namespace. TXT records are also not covered by
 Ol>> FTS-5004.

 PG> FTS-5004 specifies contents of a DNS zone for being DDN. And according to
 PG> this FTS no records other than generated from the nodelist should appear
 PG> in the zone.

Is this how DNS is intended to work? The binkp client also does not care about
anything that does not match *.f*.n*.z*.ddn-zone.


 PG> Formally even SOA record violates this FTS, and I think this
 PG> should be fixed to allow additional information which may be useful.

or MX, TXT records for SPF, ...


 PG> Alexey (author of this FTS) told that DNS zone which contains additional
 PG> information (such as IP addresses of points) is not DDN according by
 PG> FTS-5004.

Interesting. To quote FTS-5004:

P - Point Number:
    If the system is a point rather than a node then
    this is their point number at that node.
    Optional. If ".P" is missing then assume 0 (node itself).

What is the point in mentioning points in the FTS, when there are no points in
the world nodelist and everything else is forbidden? ;)


 Ol>> Not sure what a "DDN NS zones" is supposed to mean.

 PG> DNS zone is well-known term (https://en.wikipedia.org/wiki/DNS_zone), and
 PG> "DDN NS zone" is definitely not "set of records in DNS zone".

In DNS-speak there is no such thing as a "NS zone". NS is short for nameserver
and DNS stands for Domain Name System. There is the NS record. But "NS zone"
does not compute. If people try to write standards, they should use words that
have a defined meaning or it becomes a ambiguous mess free for interpretation.

I also think DNS zones and NS records are completely irrelevant for the DDN
standard. We are talking about the DDN domain, not about zones.

"A domain is a logical division of the DNS name space whereas a zone is
physical, as the information is stored in a file called a zone file."

But if the standard did really mean DNS zone, you would only need a NS record,
that sets a boundary to the zone like

something.ddn.example.com  IN NS  ns2.example.com

"A zone is a domain less any sub-domains delegated to other DNS servers"


 PG> May be, we can change this paragraph to something like "DDN MUST contains
 PG> all information about IP addresses from the world nodelist and MUST NOT
 PG> modify this information. DDN CAN contain information from other sources
 PG> (pointlists, fresh network segments etc) only in addition to information
 PG> from the world nodelist".

Question is: if there were multiple DDN services, would it be okay that each
one could have different additional records from other sources or should every
DDN be exactly the same?


 PG> Sorry, it's not about using binkp.net by sysop in the mailer for resolve
 PG> nodes. Sure, nobody can forbid it. It's about using binkp.net in INA flag
 PG> in the nodelist - Alexey says it's XAB because it violates FTS-5004.

Now I get it. I would agree that it is problematic, because the z*.binkp.net
namespace also includes records that are generated from the nodelist. Why not
use *.dyn.binkp.net and *.node.binkp.net addresses in the nodelist -> problem
solved.

(Still, threatening to DDoS binkp.net is dumb)

---
 * Origin: War is Peace. Freedom is Slavery. Ignorance is Strength.