Name resolution, service discovery: Difference between revisions

From Helpful
Jump to navigation Jump to search
Line 27: Line 27:
<!--
<!--


DNS is the service that makes hostnames work on the internet:
DNS is best known as the service that makes hostnames work on the internet:
at the core, you give it a hostname, it gives you an IP addresses  
you give it a hostname, it gives you an IP addresses.


DNS has not fundamentally changed since the early eighties, though it has been augmented.
It actually does a few things more than that - though indeed, the hostname part has not fundamentally changed since the early eighties{{verify}}.




DNS is hierarchical, and thereby somewhat distributed.






You ''could'' have your own DNS service
'''Is there just one DNS system?'''
 
You ''could'' have your own DNS service, but by and large, there is a single overall internet DNS service that everyone shares,
and we want to stick with for names to be consistent and not confusing.
 
...until the world decides to [https://en.wikipedia.org/wiki/Splinternet splinter] the internet.
: which China started doing long ago
: Russia seems to be flirting with the idea of as well, [https://en.wikipedia.org/wiki/Roskomnadzor Roskomnadzor] in 2022 testing some BGP fuckery that effectively blocked facebook, twitter, instagram. The gun-to-heads control of the Ukrainian internet during the war also deserves mention
 


You ''could'' locally add your own hostnames on top of internet DNS.


...but by and large, there is a single overall internet DNS service that everyone shares,
and we want to stick with for names to be consistent and not confusing.
{{comment|(...until the world decides to [https://en.wikipedia.org/wiki/Splinternet splinter] the internet - china's doing well, and russia seems to be playing with the idea)}}




These here are notes for myself.
'''Hierarchy'''


If you ''need'' to know any of this for work reasons, you should be reading a good book instead of this page.
DNS is hierarchical,  
and thereby has distributed responsibilities.


In practice it is also distributed for lower latency (and some redundancy) via [[Anycast]].




UDP port 53 for lookups,
You ''could'' locally add your own hostnames on top of internet DNS,
TCP port 53 for [[#Zone transfers|zone transfers]].
but most reasons end users would want to ('add thing on my own network') is solved more easily with local [[Multicast DNS]].


(Port 5353 is used by [[multicast DNS]] systems, which is not directly related to basic DNS)




Line 64: Line 68:




If you wanted to know the IP for {{inlinecode|www.example.com}}, considered {{inlinecode|www.example.com.}}, intuitively something like the following happens:
If you asked for IP for {{inlinecode|www.example.com}}, considered {{inlinecode|www.example.com.}},  
then conceptually something like the following happens:


We start by asking the root server (basically hardcoded into DNS clients).
We start by asking the root server (basically hardcoded into DNS clients).
: "Hey root server, do you know www.example.com. ?"
: "Hey root server, do you know www.example.com. ?"
: Root server: "I don't know, that's delegated; the nameserver for .com. is server X"
: Root server: "I don't know, that's delegated; the nameserver for .com. is server X" (a.k.a. the gTLD serves)
   
   
: "Hey server X, do you know www.example.com. ?"  
: "Hey server X, do you know www.example.com. ?"  
: Server X: "I don't know, that's delegated; the nameserver for example.com. is server Y"
: Server X: "I don't know, that's delegated; the nameserver for example.com. is server Y" {{comment|(...or "I don't know of example.com")}}


: "Hey server Y, What's the IP for www.example.com?"
: "Hey server Y, What's the IP for www.example.com?"
: Server Y: "Here it is."
: Server Y: "That's what I'm here for.  Here it the record mentioning the IP."


For that in more mechanical terms, see the output of something like {{inlinecode|dig +trace +nodnssec example.com}}
For that in more mechanical terms, see the output of something like  
dig @a.root-servers.net +trace +nodnssec example.com
(the explicit nameserver is there because on modern linux, systemd-resolved may be preventing this from working as predicted)




Line 109: Line 116:
Note that NS records within the domain itself are a bootstrap issue.  
Note that NS records within the domain itself are a bootstrap issue.  
That is, if example.com has a NS record pointing at ns1.example.com, that's sort of pointless because we probably needed to know ns1.example.com's IP address to be able to get this NS record.
That is, if example.com has a NS record pointing at ns1.example.com, that's sort of pointless because we probably needed to know ns1.example.com's IP address to be able to get this NS record.
These here are notes for myself.
If you ''need'' to know any of this for work reasons, you should be reading a good book instead of this page.
UDP port 53 for lookups,
TCP port 53 for [[#Zone transfers|zone transfers]].
(Port 5353 is used by [[multicast DNS]] systems, which is not directly related to basic DNS)


-->
-->

Revision as of 17:58, 6 November 2023

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Name resolution

hosts file

DNS

Authoritative and non-authoritative; iteration and recursion

Duplication and minimizing load

Resource record; zones

A
NS, SOA, and delegation
CNAME
TXT
MX
AAAA
HINFO
PTR

DNSSEC records

Zone transfers

NXDOMAIN records

Domain name transfers

Public DNS

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The first few also known as

'simple-to-remember things to ping to test connectivity without name resolution'
'easy for helpdesk to speak out over the phone if they suspect DNS issues'
4.2.2.2  Level 3, also 4.2.2.1, 4.2.2.3
8.8.8.8  Google, also 8.8.4.4
1.1.1.1  cloudflare DNS, also 1.0.0.1


UltraDNS

OpenDNS

Unsorted

Internet TLDs

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

infrastructure top-level domain

.arpa

Mainly meant as a transition from ARPANET to DNS naming.

Has stuck around because it was used to implement reverse DNS lookup, and has found some similar uses since.

testing top-level domains (tTLD)

.test
.example
.invalid
.localhost

...some of those to say to should never become part of the DNS root zone.


country code top-level domains (ccTLD)

Strongly correlated to ISO 3166-1 alpha-2 codes; see also Language codes, country codes

...though there are a few unused
...and a few that are not in that list, e.g. uk, eu, ac (arguably GeoTLDs instead)

There were quickly between 200 and 300 of these in use.

generic top-level domains (gTLD)

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

The original set of top level domains (1984(verify)) was roughly

.com - intended for commercial things, but not effectively restricted
.net - originally for network infrastructure, since unrestrcted
.edu - US education (mostly)
.gov - US government (mostly)
.mil - US military (mostly)
.int -
.org - was meant as a 'doesn't fit into the above' organisations, now unrestricted and has some correlation to less-commerical organisations

and later the ccTLDs (1985(verify))


Those became managed by ICANN once it existed(verify)

ICANN (founded 1997) has introduced

2000 .aero, .biz, .coop, .info, .museum, .name, .pro
2004 .asia, .cat, .jobs, .mobi, .tel, .travel

...so up to then there were about two gTLD (alongside the ccTLDs, infrastructure and testing(verify))

around 2009 ICANN introduced the New gTLD Program which is basically the start of hundreds of extra TLDs, some of which can be categorized into the below






Geographic gTLD (GeoTLD)

"....invoking an association with a geographical, geopolitical, ethnic, linguistic or cultural community"

Initially (2007?(verify)) only

.cat (Catelan language)
.asia
.eu (European Union)

There have since been thousands of proposals (2000+ in 2012), things like:

.london
.paris
.berlin
.nyc
.amsterdam
.wien (Vienna)
.toronto (Toronto)
.αθήνα (Athens)
.bcn (Barcelona)
.lat (Latin America)
.saarland
.kiwi (New Zealand)
.quebec
.corsica
.africa
.scot
.cym (Wales, Cymru)
.cymru (Wales, Cymru))
.wales (Wales)
.vlaanderen (Flanders)
.bzh (Breton community)
.scot (Scots community)
.eus (Basque language)
.gal (Galician language)
.上海 (Shanghai)

...which seem to be examined and approved on an ongoing basis(verify).

Apparently 50 of them are current?(verify)


https://en.wikipedia.org/wiki/GeoTLD

https://geotld.group/geotlds/

restricted generic top-level domains (grTLD)
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Domains you can only get after you prove eligibility.

This includes

.name - personal name
.pro - certified professionals
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Sponsored by specific organizations, restricted by said agencies.

Older ones considered sponsored:

.edu - US education (mostly)
.gov - US government (mostly)
.mil - US military (mostly)
.int -


Newer ones include:

.aero
.asia
.cat
.coop
.jobs
.museum
.post
.tel
.travel
.xxx


https://en.wikipedia.org/wiki/Sponsored_top-level_domain

Internationalized country code top-level domains (IDN ccTLD)

Internationalized domain name (IDN) allows non-ASCII coding in DNS, using IDNA encoding (see also punycode).


This is mostly used for ccTLDs in the relevant language's own alphabet,

There are currently around 50 in use.

https://en.wikipedia.org/wiki/Internationalized_country_code_top-level_domain

See also

NSS

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Originally, account and host information came from /etc/{passwd, group, shadow, hosts}, which you could sort of do yourself though usually had a library or other interface for.

(note that hosts.allow and hosts.deny is not part of NSS, but of tcpwrappers and applies only to it(verify))


Then NIS and DNS and such came about, and it became a more pressingly good idea to have a single interface unify lookup of accounts, passwords, and hostnames.

This is basically what the Name Service Switch (NSS) subsystem is. It's part of glibc and used to backs calls like getaddrinfo() and gethostbyname().

NSS allows dynamically hooking things into hostname resolution, user/group, password. Since you can have multiple sources, it also lets you configure when and how each is used and in what order.



A sensible question is "So what about PAM? it deals with similar stuff."

PAM is primarily the logic of how to apply such sources of information (when and how to authenticate, what to allow, etc.), but not itself the thing that accesses them.

So in most ways, it's a generalizing layer on top of NSS, and other things.

So yes, there are a subset of things you can get done in either NSS and PAM. (which you'd choose depends a bit on what your program is. If you're part of the OS you would probably use PAM because it ends up being more flexible, if you're just a random application that wants to look up a username or such you would probably use NSS because it's easier to hook into than PAM.


There's some funny specific cases, particularly hostname lookup.

Some command line tools (e.g. dig, host, nslookup) only query the nameserver, and bypass your local system (so great for people debugging DNS)
"I want hostname lookup the same way the OS does" basically means using gethostbyname() (or getent), which is actually backed by NSS, so whatever /etc/nsswitch.conf configures

That NSS configuration is at /etc/nsswitch.conf and the relevant line is usually at least (the order can vary):

hosts:  	 files dns myhostname 

On workstations it may be something like:

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

Where

order is fallback style
files refers to files like /etc/hosts,
dns is basically whatever's configured in /etc/resolv.conf
some form of mDNS
(mdns4_minimal: 4 to avoid timeout-based delays when you don't use IPv6, and _minimal to avoid attempts to resolve things that don't end in .local (which is why the "if tried but not found, then give up resolving it completely" makes sense))
myhostname is /etc/hostname and /etc/hosts (mainly to ensure your own hostname always resolves).
may be added last in a "well in case everything fails at least we have a name"
there are a few more, like nis, nisplus, hesiod, windbind, wins, systemd


local DNS (mDNS, LLMNR)

Multicast DNS is the concept of having a functional subset of DNS communicating on your LAN via local multicast.


Basically exists in two forms:

  • Apple's mDNS (moderately common)
  • Microsoft's LLMNR [1] (less common)


The two are similar, and apparently the only reason they aren't the same thing is some popcorn-worthy drama - mDNS is essentially the standard, and MS continues to do their own thing.


mDNS notes

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

So how do you resolve .local?

OSX does this pretty natively
Linux does lookups typically through avahi, so requires that to be installed, and hooked into nss.
Windows by default chooses not to support mDNS (or, since ~Win10, only some of it), because of LLMNR related grump.
There's Bonjour for windows, though a newer version of it is only available packaged with iTunes and a few other things[2].
Also note
some apps have their own mDNS built in
devices (like printers) may have it to ease finding them for initial setup





https://serverfault.com/questions/118237/how-to-use-zeroconf

https://en.wikipedia.org/wiki/.local


http://archive.is/mkDws

https://serverfault.com/questions/118652/how-to-use-bonjour

https://www.ibm.com/support/knowledgecenter/en/SSB2MG_4.6.0/com.ibm.ips.doc/concepts/gx_gv_using_avahi.htm

-->

On zeroconf and service discovery

Zeroconf refers broadly to whatever allows automated network configuration, and also to discovery of services available on the (sub)net.

A little more precisely:

assignment of addresses for devices,
resolution of hostnames,
location of network services.


The first wasn't really necessary due to the already-existing DHCP, so zeroconf may largely refer to the latter two, often:

  • Multicast DNS for name resolution, often either
    • mDNS (all platforms)
    • LLMNR (mostly for windows)
  • plus some means of service discovery, for example
    • Apple's DNS-SD (DNS based Service Discovery)
    • Microsoft's SSDP (Simple Service Discovery Protocol), part of UPnP [3]


Implementations:

  • Bonjour (probably the most common Zeroconf setup) (previously 'Rendezvous')
    • from Apple
    • is mDNS and DNS-SD
    • available for Mac, Linux, other POSIX, and Windows
  • Avahi [4] [5]
    • is mDNS and DNS-SD
    • available for Linux, BSD
  • XLLMNRD
    • is LLMNR on linux
  • systemd-resolved
seems to mostly be a local cache(verify)
  • Howl (old, not developed anymore [6])
  • UPnP allows network device setup [7]
(though its lack of authentication makes it a security problem in a few cases)
  • Windows CE 5.0 has an LLMNR-based implementation
  • Windows 10 seems to have an mDNS for printers
apparently for proper mDNS, you should disable that and install Bonjour(verify)


Related:

  • SLP (Service Location Protocol) [8]
seemlingly aimed at printers, also used for some other shared services(verify)
systems that already use LDAP will probably use that instead of SLP
  • WS-Discovery [9]
multicast
Device/service coordination
Device/service coordination
  • Other device configurers: