# hostname="?"



## hruodr (Mar 11, 2021)

What do you use as "top level domain" in rc.conf variable _hostname_ if you do not have a registered domain?

I use .local (hostname="machinename.local"), but I am not sure if that is right.


----------



## SirDice (Mar 11, 2021)

Just pick something that doesn't exist, .local can be problematic as it's used by ZeroConf/mDNS. For my systems at home I use .home.


----------



## hruodr (Mar 11, 2021)

Yes, that was a solution before the inflation of TLDs.

".home" can be registered at any moment. There is perhaps some warranty that this will not happen with
.local, but I do not know if there is any risk using it.


----------



## SirDice (Mar 11, 2021)

hruodr said:


> ".home" can be registered at any moment.


TLDs don't change that often. I'm not sure you understand the difference between a domain name and a top level domain (TLD).


----------



## zirias@ (Mar 11, 2021)

Really safe to use (for all times): https://tools.ietf.org/html/rfc2606
`.localhost` can't be used as it implies resolving to `127.0.0.1`.
The others are suboptimal, but any other choice could clash with a really existing TLD some time in the future.


----------



## hruodr (Mar 11, 2021)

Of course I understand the difference!!!! 

But did you not see the inflation of TLDs??? There is almost everything as TLD.


----------



## zirias@ (Mar 11, 2021)

And that's exactly why these few TLDs are reserved. Unfortunately, none of them is meant for "home networks".


----------



## SirDice (Mar 11, 2021)

hruodr said:


> But did you not see the inflation of TLDs??? There is everything.


Yes, a lot more have been added some time ago. But the process of registering a TLD is not as easy, new TLDs need to be approved by IANA.


----------



## hruodr (Mar 11, 2021)

Zirias said:


> but any other choice could clash with a really existing TLD some time in the future.



Aesthetically is .local also suboptimal, and yes, if zeroconf disappears, the "warranty" disappears also.

I wonder why the "authorities" did not consider "normal" home computer users, offline users, etc.


----------



## zirias@ (Mar 11, 2021)

Just inventing a TLD has always been a risk.

There are 3 ways to do it properly:

Use your own properly registered domain, or a subdomain of it (that's what I do)
Use a subdomain you might get for free e.g. from a dyndns service (what I did in a distant past)
Use one of the reserved TLDs


----------



## SirDice (Mar 11, 2021)

hruodr said:


> I wonder why the "authorities" did not consider "normal" home computer users, offline users, etc.


That's a good question. There are special TLDs like .test. They did also reserve special IP addresses (The private ranges; RFC1918) so why not one or two special case TLDs to be used specifically for home or (internal) enterprise networks.


----------



## VladiBG (Mar 11, 2021)

Reserved Top Level Domain Names
					

The Internet Domain Name System (DNS) defines a tree of names starting with root,



					tools.ietf.org
				




Any of those are ok


> .local
> .localdomain
> .domain
> .lan
> ...


----------



## zirias@ (Mar 11, 2021)

It seems there was an attempt to do so, see e.g. https://serverfault.com/a/937808/297939, but IANA didn't include them in their reserved list.

VladiBG it doesn't really help as long as IANA doesn't list them: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml – so far, it's just a suggestion.

*edit:* An argument against this kind of reserved TLDs you will read from time to time is the clashes it would create when trying to interconnect two such private networks (e.g. via VPN), so globally unique names are always preferred. Of course, the same would result from "misuse" of the reserved TLDs specified in original RFC2606.


----------



## hruodr (Mar 11, 2021)

Zirias said:


> _*[FONT=monospace]VladiBG[/FONT]*_ it doesn't really help as long as IANA doesn't list them: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml – so far, it's just a suggestion.



Yes, unfortunately seems to be only a suggestion, they are not reserved, but registering them will cause 
troubles to a lot of people, probably they will not dare to do it. A de facto standard?

.lan looks nice. I hope once will be reserved.


----------



## VladiBG (Mar 11, 2021)

Yeah you are right like .host is https://www.iana.org/domains/root/db/host.html already registered as public.

For my test lab network i use .local domain so the only reserved domains are those from https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml


----------



## olli@ (Mar 11, 2021)

Well, you can use `.xxx` because this is only used by spammers anyway …


----------



## Jose (Mar 11, 2021)

Register a domain and use it in your home network. Use split-horizon DNS if you need a public presence too.


----------



## hruodr (Mar 11, 2021)

olli@ said:


> Well, you can use `.xxx` because this is only used by spammers anyway …


Thanks for the insult.


----------



## Jose (Mar 11, 2021)

.xyz domains are just $1.00/year. However, I (and many other mail sites) block them because they do produce a lot of SPAM. It would be a safe and inexpensive solution for an internal network, though.


----------



## Snurg (Mar 12, 2021)

Zirias said:


> Use one of the reserved TLDs


Thank you, this is the solution.
I guess this IETF handling is intended to motivate people to waste money for registering a less "embarrassing" domain.
But what else to expect else from a commercial corporate institution, honestly?


> Reserved Example Second Level Domain Names​
> The Internet Assigned Numbers Authority (IANA) also currently has the
> following second level domain names reserved which can be used as
> examples.
> ...



(Expand if you want to see the "embarrassing" stuff)

So, no real need for split DNS, if you can live as an example.


----------



## richardtoohey2 (Mar 12, 2021)

hruodr said:


> I wonder why the "authorities" did not consider "normal" home computer users, offline users, etc.


It's not exactly related but it reminded me of this:






						There is no reason anyone would want a computer in their home. - Computing History
					

There is no reason anyone would want a computer in their home. Ken Olsen, president, chairman and founder of Digital Equipment Corporation DEC 1977 Ken Olsen made this statement in 1977. It now see...



					www.computinghistory.org.uk
				



_
"There is no reason anyone would want a computer in their home."
Ken Olsen, president, chairman and founder of Digital Equipment Corporation (DEC) 1977_


----------



## Snurg (Mar 12, 2021)

(sry OT)
Yes, there is still much "old" thinking around.
Even Windows is apparently able to kill processes in D-state...
But some operating systems' people consider doing such blasphemic, prefer the users having to reboot production servers.


----------



## Deleted member 30996 (Mar 12, 2021)

hruodr said:


> What do you use as "top level domain" in rc.conf variable _hostname_ if you do not have a registered domain?
> 
> I use .local (hostname="machinename.local"), but I am not sure if that is right.


/etc/rc.conf
hostname="jigoku"

I set the machinename during the base system build and when it gets to the part about configuring DCHP and choosing a network name I click on through and leave that blank. The machinename of my different laptops appear in the router tables and I'm good to go.


----------



## hruodr (Mar 12, 2021)

Trihexagonal said:


> /etc/rc.conf
> hostname="jigoku"



I like that short names, unfortunately many programs do need the form "host.domain".


----------



## olli@ (Mar 12, 2021)

hruodr said:


> I wonder why the "authorities" did not consider "normal" home computer users, offline users, etc.


In this case, the “authorities” would be the IANA and the IETF.

Offline users can chose any TLD name they want, of course, because there cannot be a conflict.

Basically, home users have several options (beside registering a real domain, of course):

The most correct approach is to use the special TLD `.home.arpa` according to RFC 8375.
The next best approach is to use the reserved TLD `.example` or `.example.net`. According to RFC 6761, these are not handled specially by software, appliances, name servers etc. (unlike the other reserved TLDs).
If you don’t like any of the above, it’s probably ok to use an existing TLD where the chance of a conflict is sufficiently low. For example, you may use `.xxx` if you don’t intend to access web sites in that TLD, or exchange e-mails with users who have addresses with that TLD. Make sure that you don’t leak addresses to the internet, i.e. if you run a DNS server, it must not send replies concerning `.xxx` (or whatever you chose) to the outside.


----------



## hruodr (Mar 12, 2021)

olli@ said:


> Basically, home users have several options (beside registering a real domain, of course):


No way to have a short name.

I use something that corresponds to your third point, .local, and would use .lan

Perhaps the more people use .lan, the more is possible that it be reserved for local networks.


----------



## olli@ (Mar 12, 2021)

hruodr said:


> No way to have a short name.


Why do you want a short name? You don’t have to type it all the time, so the length doesn’t matter much. Apart from that, I think `.example` is fairly short.
 


> I use something that corresponds to your third point, .local, and would use .lan


That’s not a very good idea.
`.local` is reserved for link-local addresses in the context of multicast DNS, see RFC 6762. Using it for other purposes might cause problems.
`.lan` currently does not exist at all, and it is not reserved or otherwise special. That means that ICANN may delegate it to a registry for official use at any time.
 


> Perhaps the more people use .lan, the more is possible that it be reserved for local networks.


That’s not how assignment by the IANA works.


----------



## SirDice (Mar 12, 2021)

hruodr said:


> I like that short names, unfortunately many programs do need the form "host.domain".


Actually, it has to be host.domain.tld. 



hruodr said:


> No way to have a short name.


Set `search` or `domain` correctly in resolv.conf. `search` is useful if you have multiple (sub)domains. `domain` can only have one and this should be the domain of the host itself. 

For example:

```
nameserver 1.2.3.4
search example.com mydomain.home
```
If you use a 'short' name like myhost in client applications, the search parameter from resolv.conf will expand this automatically to search for myhost.example.com and myhost.mydomain.home.

Similarly with `domain`

```
nameserver 1.2.3.4
domain example.com
```
When a client calls for a 'short' name, the `domain` is automatically appended. So a `ping myhost` will be resolved as myhost.example.com.


----------



## hruodr (Mar 12, 2021)

SirDice said:


> Actually, it has to be host.domain.tld


Well, I think _tld_ is a full qualified domain, I remember once read the definition, but all depends on what the
programs expect.


----------



## SirDice (Mar 12, 2021)

hruodr said:


> Well, I think _tld_ is a full qualified domain, I remember once read the definition, but all depends on what the
> programs expect.


If I recall correctly a lot of applications that need a FQDN specifically look for two dots in the hostname. Hence the myhost.domain.tld notation.


----------



## Mjölnir (Mar 12, 2021)

`hostname`: `t450s.local.lan`


----------



## hruodr (Mar 12, 2021)

SirDice said:


> If I recall correctly a lot of applications that need a FQDN specifically look for two dots in the hostname.


I have a server with name _name.tld_ running `sendmail` as MTA, cyrus-imap, apache, and other 
software, without problems. But it would be not a surprise if some other software at some point make troubles.

BTW. It was much more complicated to get cyrus-imap than `sendmail` to work. The old 
uw-imap worked out of the box, it was a nice solution for small personal servers, but unfortunately 
is not mantained anymore.


----------



## olli@ (Mar 12, 2021)

SirDice said:


> If I recall correctly a lot of applications that need a FQDN specifically look for two dots in the hostname. Hence the myhost.domain.tld notation.


But that behavior would be an RFC violation. _<hostname>.<domain>_ with a single dot is a valid FQDN.

By the way, RFC rules are not always intuitive. For example, few people (even among people familiar with IP networking) know that `127.1` (one dot!) is syntactically a valid numeric IP address, and it is equivalent to the “dotted quad” `127.0.0.1`. Try `ping 127.1`, for example.


----------



## SirDice (Mar 12, 2021)

olli@ said:


> But that behavior would be an RFC violation. _<hostname>.<domain>_ with a single dot is a valid FQDN.


That's not my understanding. Not unless you define _domain_ to be _name.tld_. So a host's FQDN always has at least two dots in it. Technically it's actually three, hostname.domain.tld. (note the ending dot) to make it absolute.


olli@ said:


> For example, few people (even among people familiar with IP networking) know that `127.1` (one dot!) is syntactically a valid numeric IP address, and it is equivalent to the “dotted quad” `127.0.0.1`. Try `ping 127.1`, for example.


Even fewer will know `ping 2130706433` works too


----------



## Deleted member 66267 (Mar 12, 2021)

hruodr said:


> I like that short names, unfortunately many programs do need the form "host.domain".


I use failure.bsd.home as my hostname. This will shut up sendmail and stop it from blocking my FreeBSD to boot.


----------



## Mjölnir (Mar 12, 2021)

Advantage of open source: anyone can participate.
Some open source SW is of the finest quality & much better than the most expensive commercial counterpart.
Disadvantage of open source: anyone can participate...
Many open source SW is beyond crap, and thus it's just a precautionary measure to avoid trouble by e.g. keep such "variables" like the hostname to match the most commonly used pattern & conform to a very simple syntax


----------



## hruodr (Mar 12, 2021)

SirDice said:


> That's not my understanding. Not unless you define _domain_ to be _name.tld_. So a host's FQDN always has at least two dots in it. Technically it's actually three, hostname.domain.tld. (note the ending dot) to make it absolute.



Look here, from /usr/share/sendmail/cf/README :



> relay_entire_domain
> This option allows any host in your domain as defined by
> class {m} to use your server for relaying.  Notice: make
> sure that your domain is not just a top level domain,
> ...


This does imply that a tld is a domain, just a top level domain.


----------



## SirDice (Mar 12, 2021)

Yeah, I had a stroll (need to get outside more, been cooped up at home for a year now) and had some time to ponder on this. I believe we're both right. Yes, _hostname.domain_ is a perfectly fine FQDN _internally_. On the internet however it's just not going to happen. For the simple reason you just cannot get a hostname registered on the root servers. So for internet hostnames an FQDN will most certainly have at least two dots.


----------



## hruodr (Mar 12, 2021)

Mjölnir said:


> Disadvantage of open source: anyone can participate...
> Many open source SW is beyond crap


Yes, clueless people participate and call valuable software crap, and want crap on their desktop.


----------



## hruodr (Mar 12, 2021)

SirDice said:


> So for internet hostnames an FQDN will most certainly have at least two dots.


In any case seems to be good practice.


----------



## zirias@ (Mar 12, 2021)

SirDice said:


> On the internet however it's just not going to happen. For the simple reason you just cannot get a hostname registered on the root servers. So for internet hostnames an FQDN will most certainly have at least two dots.


There's no *technical* problem as you can easily add A and AAAA records to a zone for the domain itself. Just in practice, most people will use them only as aliases.


----------



## SirDice (Mar 12, 2021)

Zirias said:


> There's no *technical* problem as you can easily add A and AAAA records to a zone for the domain itself.


Sure, that's one way around it but that's technically not a hostname, it's an address record for the domain.


----------



## hruodr (Mar 12, 2021)

Zirias said:


> There's no *technical* problem as you can easily add A and AAAA records to a zone for the domain itself.


I have such a configuration, but you see above the problems you can get, and I would not wonder if some
software expect in spite of it two dots.



SirDice said:


> but that's technically not a hostname



Who says what is a hostname? One gives a name, again, from sendmail:



> This can happen if you give your host a name
> like example.com instead of host.example.com.


----------



## zirias@ (Mar 12, 2021)

Whether the record is on the domain itself or below it is only of internal interest for the resolver, and it would be perfectly allowed to use the domain as FQDN. As I said, it's probably very uncommon in practice. Not only for software taking assumptions not warranted by the standards – but kind of funny it's sendmail again…


----------



## hruodr (Mar 12, 2021)

Zirias said:


> Not only for software taking assumptions not warranted by the standards – but kind of funny it's sendmail again…



It is allowed and hence standard, and sendmail is here conforming the standard, it is not following unwritten rules.


----------



## zirias@ (Mar 12, 2021)

You're contradicting here what you cited *yourself* from sendmail README earlier.


----------



## hruodr (Mar 12, 2021)

Zirias said:


> You're contradicting here what you cited *yourself* from sendmail README earlier.



It is no contradiction. It just warns to use an allowed name instead of forbidding you to use the allowed name.

It is your freedom to use that name even if it has consequences.


----------



## zirias@ (Mar 12, 2021)

Sure, that's also a way to defend that sendmail might take a TLD for a valid domain.


----------



## hruodr (Mar 12, 2021)

It has consequences, if you take that name and put the option _relay_entire_domain._

It is also allowed to do as root user: `rm -r /`

If you do not like that, then you should use Windows that cares that you do not do stupid things.


----------



## zirias@ (Mar 12, 2021)

You ARE aware that a domain and a TLD are different things, right?


----------



## SirDice (Mar 12, 2021)

We already had that covered. But a TLD is just a domain too. On the internet it has a special meaning (due to IANA) but for _internal_ DNS it doesn't really matter.


----------



## zirias@ (Mar 12, 2021)

It's not "just a domain", but of course, having a hostname with just ONE dot will confuse software that doesn't make this distinction. Technically, a TLD is a domain, but it does have specific semantics (e.g. can't be registered by anyone, does not name any organization's network, etc).

Therefore it WOULD be a sane assumption that an MTA doesn't just enable relaying for a TLD.

Anyways, the insanity goes even further, look at this: https://www.iab.org/documents/corre...statement-dotless-domains-considered-harmful/

Do domain name registries have marketing departments?


----------



## SirDice (Mar 12, 2021)

Zirias said:


> Technically, a TLD is a domain, but it does have specific semantics (e.g. can't be registered by anyone, does not name any organization's network, etc).


Yes, but this assumes you're talking about _internet_ registrations. For _internal_ DNS this is irrelevant.


----------



## hruodr (Mar 12, 2021)

Also the root domain (.) is a domain. The correct way to write a domain is with a dot at the end representing this root domain. This is very important when configuring DNS.


----------



## hruodr (Mar 12, 2021)

Zirias said:


> Therefore it WOULD be a sane assumption that an MTA doesn't just enable relaying for a TLD.


You can also enable to relay for anybody, namely for the root domain. It is your decision.


----------



## olli@ (Mar 12, 2021)

A TLD is a valid domain. A domain consists of one or more components. The first component is also called TLD, but it is a valid domain on its own, too. So, a valid FQDN can contain just one dot.

For example, `www.de` is a valid FQDN on the internet. It has an “A” record, so you can connect to it (it’s running a small web server, although it’s just redirecting elsewhere).

In theory, you can even put “A” records on a TLD like `de`. Technically this is perfectly valid, and there is nothing in the RFCs that would disallow that. In practice it isn’t done because users would have to use the canonical (some call this “absolute”) form to access it, and most users don’t know how to do this. Hosts usually perform canonicalization, i.e. the resolver appends its own domain to names that are unqualified, i.e. names that don’t contain a dot. To write a TLD as a qualified (“absolute”) name, you have to append a dot. So, to access a hypothetical web server running on the TLD `de`, you would have to write `https://de./` (note the dot). If you’re curious, you can try this yourself at home with BIND and a zone file for the `example` domain.


----------



## zirias@ (Mar 12, 2021)

That's all correct, and simply put, a domain is "qualified" as soon as it contains at least one dot. I'm just saying an option trying to derive your domain from your hostname (both technically FQDNs) by just stripping off everything up to the first dot is guesswork that only gives the correct result if you follow common practices. Maybe the best way for an MTA would be not to offer such an option at all and require explicit configuration of domains to relay for.


----------



## olli@ (Mar 12, 2021)

Zirias said:


> That's all correct, and simply put, a domain is "qualified" as soon as it contains at least one dot. I'm just saying an option trying to derive your domain from your hostname (both technically FQDNs) by just stripping off everything up to the first dot is guesswork that only gives the correct result if you follow common practices. Maybe the best way for an MTA would be not to offer such an option at all and require explicit configuration of domains to relay for.


That’s what sendmail does.

Actually, for the most part, sendmail does not make a distinction between host names and domain names. It doesn’t have to, because technically it’s the same. It only has to provide special handling for unqualified names (canonicalization). This is fully configurable, you can even switch it off completely if that makes sense for your site.


----------



## Jose (Mar 12, 2021)

hruodr said:


> I have a server with name _name.tld_ running `sendmail` as MTA, cyrus-imap, apache, and other
> software, without problems. But it would be not a surprise if some other software at some point make troubles.


That's a root domain record. They're very popular nowadays. I would much rather have proper host records ("www" should be a host or an alias to a host, for example), but I appear to be very much in the minority.


hruodr said:


> Also the root domain (.) is a domain. The correct way to write a domain is with a dot at the end representing this root domain. This is very important when configuring DNS.


The dot is not a domain. It's used to prevent origin substitution, both in zone files, and for the resolver, as Olli@ points out. I think origin substitution is also called "canonicalization", which is quite a typeful.


hruodr said:


> BTW. It was much more complicated to get cyrus-imap than `sendmail` to work. The old
> uw-imap worked out of the box, it was a nice solution for small personal servers, but unfortunately
> is not mantained anymore.


I used UW-IMAP for years, and was also very happy with it. Eventually my mailbox file got too big and started causing problems. I've just read that the author of UW-IMAP refused to add support for maildirs due a disagreement with DJB:




__





						FUD
					






					www.courier-mta.org


----------



## Jose (Mar 12, 2021)

olli@ said:


> Actually, for the most part, sendmail does not make a distinction between host names and domain names. It doesn’t have to, because technically it’s the same.


I suspect this behavior was deliberately added when MX records were introduced. The standard before then was that mail would be sent to a particular host with an A record. This is from back in the day when having a mail account meant having a user account on some big Unix machine on campus. That approach works to this day if your domain does not have an MX record.

DJB gets into this in his IPv6 critique:


			https://cr.yp.to/djbdns/ipv6mess.html


----------



## Mjölnir (Mar 12, 2021)

This is a funny thread... are you revealing the philosophical aspects of DNS syntax & semantics?


----------



## olli@ (Mar 15, 2021)

Jose said:


> The dot is not a domain. It's used to prevent origin substitution, both in zone files, and for the resolver, as Olli@ points out. I think origin substitution is also called "canonicalization", which is quite a typeful.


Actually, _both_ is correct.
 
Technically, the dot _is_ a domain, as hruodr mentioned. You can think of it as the zone that contains the delegations for com, net, org, info etc. Just try the command `host -a .` or `drill . any` that lists the delegation for the root name servers.
As an analogy, it’s similar to “/” that is the root directory in a file system that contains entries for bin, usr, var, etc.
 
At the same time, the dot is used to mark an FQDN as absolute, to prevent appending the local domain. Just like “/” is used to denote an absolute path name, to prevent prepending the current working directory.
 


Jose said:


> I suspect this behavior was deliberately added when MX records were introduced. The standard before then was that mail would be sent to a particular host with an A record. This is from back in the day when having a mail account meant having a user account on some big Unix machine on campus. That approach works to this day if your domain does not have an MX record.


Of course, that’s what the RFC requires. If there is no MX record, then the address record (A or AAAA) is used, with an implicit preference of 0.
But that has nothing to do with the meaning and format of FQDNs.

Actually, the (E)SMTP standard explicitly states that FQDNs may have just one component, and that foo@com is a valid email address for the com TLD (at least formally – I’m not saying that this particular address actually exists).


----------



## Jose (Mar 17, 2021)

Thank you for helping me understand why reverse-mapping domain names are backwards.


olli@ said:


> Technically, the dot _is_ a domain, as hruodr mentioned. You can think of it as the zone that contains the delegations for com, net, org, info etc.


Turns out there's another very special TLD under ".", "arpa".





						Chapter 3 DNS Reverse Mapping
					






					www.zytrax.com
				



Nice diagram on that page, too.


----------



## olli@ (Mar 17, 2021)

Jose said:


> Turns out there's another very special TLD under ".", "arpa".


Yes, and this gets us back to the original question of this thread, because one of arpa’s subdomains – `home.arpa` – is meant to be used as the domain for private home networks. See RFC 8375.


----------



## zirias@ (Mar 17, 2021)

olli@ said:


> Yes, and this gets us back to the original question of this thread, because one of arpa’s subdomains – `home.arpa` – is meant to be used as the domain for private home networks. See RFC 8375.


Indeed – I dismissed it earlier, having overlooked this paragraph:

```
Although this document makes specific reference to [RFC7788], it is
   not intended that the use of 'home.arpa.' be restricted solely to
   networks where HNCP is deployed.  Rather, 'home.arpa.' is intended to
   be the correct domain for uses like the one described for '.home' in
   [RFC7788]: local name service in residential homenets.
```
Then this requirement was actually solved in 2018, nice!

Still I've seen rationale about RFC2606 explicitly NOT reserving something for "home use" because it will result in networks that can't be joined later. Seems these concerns were dropped.


----------



## Jose (Mar 17, 2021)

olli@ said:


> Yes, and this gets us back to the original question of this thread, because one of arpa’s subdomains – `home.arpa` – is meant to be used as the domain for private home networks. See RFC 8375.


I don't love it. The other subdomain for ARPA, "in-addr" is clearly meant to specify the Internet protocol class. Stuffing home under arpa seems to violate Section 2.1 of RFC 3172. I know it's only a recommendation, but still, it's messy.

I thought all the other DNS protocol classes besides "IN" were obsolete. Turns out there was at least an attempt to stuff PSTN* numbers in DNS:




__





						RFC 3026:  Liaison to IETF/ISOC on ENUM
					





					tools.ietf.org
				




* Public, Switched Telephone Network


----------



## zirias@ (Mar 17, 2021)

Jose said:


> The other subdomain for ARPA, "in-addr" is clearly meant to specify the Internet protocol class.


Don't forget ip6.arpa.


Jose said:


> Stuffing home under arpa seems to violate Section 2.1 of RFC 3172. I know it's only a recommendation, but still, it's messy.


Indeed, it's a misuse. Looks like IETF wanted to reserve some TLD, but IANA didn't agree…
As long as nobody introduces a "home" protocol class that needs lookup keys below arpa, it will work


----------

