Name resolution, service discovery: Difference between revisions

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


DNS is a hierarchical (and thereby distributed) service that resolves hostnames to IP addresses ...and to some other things.
DNS is the service that makes hostnames work on the internet:
at the core, you give it a hostname, it gives you an IP addresses  


DNS is a hierarchical (and thereby somewhat distributed).
DNS has not fundamentally changed since the early eighties, though it has been augmented.


DNS has not fundamentally changed since the early eighties.


DNS is hierarchical, and thereby somewhat distributed.




It is what makes hostnames work on the internet.


You can have your own DNS service,
You ''could'' have your own DNS service
you can locally add your own on top of internet DNS,
 
but the internet's DNS is by far the largest implementation,  
You ''could'' locally add your own hostnames on top of internet DNS.
and one that we want to stick with for names to be consistent and not confusing.
 
...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)}}




Line 46: Line 49:


If you ''need'' to know any of this for work reasons, you should be reading a good book instead of this page.
If you ''need'' to know any of this for work reasons, you should be reading a good book instead of this page.




Line 54: Line 56:


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




Line 72: Line 73:
: 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"


: ISP to 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: "Here it is."


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 {{inlinecode|dig +trace +nodnssec example.com}}
Line 79: Line 80:




The root servers are run by ICANN, which e.g. delegates {{inlinecode|.com.}} to Verisign, and e.g. [[ccTLD]]s to some instance within the corresponding country.
'''Zone introduction'''
 


Delegation / separation happens mainly via '''zones'''[https://en.wikipedia.org/wiki/DNS_zone],
Delegation / separation happens mainly via '''zones'''[https://en.wikipedia.org/wiki/DNS_zone],
because they are effectively administrative containers.
because they are effectively administrative containers.


The root servers are run by ICANN, which e.g. delegates {{inlinecode|.com.}} to Verisign,
and e.g. [[ccTLD]]s to some instance within the corresponding country.


Once you get to domains owned by people or companies, they are rarely delegated further, mostly because they are used for name/brand recognition - you
ut's not until you want to give control of just part of your domain to others that zones become a more complex concept.


Because most domains owned by people or companies are used for name/brand recognition, most are not delegated further.
You'ld likely keep it in one zone.
So in a lot of practice, a domain ''often'' matches to a zone, but it's not necessary.


You'ld likely keep it in one zone, in which case zone and domain are close concepts.
It's not until you want to give control of just part of your domain to others
that zones become a more complex concept.




Line 114: Line 115:
====Authoritative and non-authoritative; iteration and recursion====
====Authoritative and non-authoritative; iteration and recursion====
<!--
<!--


A full lookup would follow all of them, though having some of them cached makes that job faster.
A full lookup would follow all of them, though having some of them cached makes that job faster.
Line 125: Line 124:


A '''non-authoritative DNS server''' has a cached copy
A '''non-authoritative DNS server''' has a cached copy
: For example, ISP's DNS, google's DNS etc. tend to cache a lot of
: For example, ISP's DNS and various public DNS services tend to cache a lot, because their function is ''only'' to answer fast
: will still have a SoA record so we can easily check{{verify}}
: will still have a SoA record so we can easily check{{verify}}


Line 133: Line 132:
'''Iterative''' servers store information.
'''Iterative''' servers store information.
: They do little more than answer direct questions and point people in the right direction.
: They do little more than answer direct questions and point people in the right direction.
: clients doin iterative lookup will communicate directly with each DNS server in a chain
: clients doing iterative lookup will communicate directly with each DNS server in a chain
 


'''Recursive''' servers know how to ask around, and do so on behalf of clients.
'''Recursive''' servers know how to ask around, and do so on behalf of clients.


A recursive server will often cache information it receives - such as common hostname (A) records, and nameserver (NS) records, to avoid all the intermediate and avoidable connections for the most common lookups.
A recursive server will frequently cache information it receives - such as common hostname (A) records, and nameserver (NS) records, to avoid all the intermediate and avoidable connections for the most common lookups.


There are footnotes to cacheing, such as how fast DNS changes will make their way to all clients.
There are footnotes to cacheing, such as how fast DNS changes will make their way to all clients.
(there are similar considerations to cacheing in clients)
(there are similar considerations to cacheing in clients)




The DNS server your computer is pointed at is probably your ISP, which will be a recursive DNS server.
The DNS server your computer is pointed at is probably your ISP, which will be a recursive DNS server.


Recursive servers will do much of the work for you.  
Recursive servers will do much of the work for you.  
Line 157: Line 154:
<!--
<!--


Masters, slaves, and caches relieve the load on the system (but of course rely on more metadata and administration - time limits for caching, synchronizing elements via [[#Zone transfers|zone transfers]], and such).
Masters, slaves, and caches relieve the load on the system (but rely on more metadata and administration - time limits for caching, synchronizing elements via [[#Zone transfers|zone transfers]], and such).


-->
-->
Line 194: Line 191:
For example:
For example:
  www  A  192.168.2.44
  www  A  192.168.2.44
...within the context of example.org means that www.example.org resolves to IPv4 address 192.168.2.44
If that's in the context of example.org, it means www.example.org resolves to IPv4 address 192.168.2.44


-->
-->
Line 205: Line 202:
can help answer your questions for hostnames in the domain - ans are authoritative for that domain.
can help answer your questions for hostnames in the domain - ans are authoritative for that domain.
: Specs say there should be at least two.
: Specs say there should be at least two.
: Lookups will also be requesting A records for these.
: Lookups will probably also be requesting A records for these.




Line 213: Line 210:
: and some values that help other servers (not clients) check that they are up to date, like a counter/timer of last change.
: and some values that help other servers (not clients) check that they are up to date, like a counter/timer of last change.


'''SOA record''' - the Start of Authority points at the 'source host',  
: also points at the 'source host', usually the primary name server, where you have split up a domain to distinct nodes {{verify}}
usually the primary name server, where you have split up a domain to distinct nodes {{verify}}




Line 228: Line 224:
   
   
  # host -t SOA example.com
  # host -t SOA example.com
  example.com has SOA record ns.icann.org. noc.dns.icann.org. 2019121406 7200 3600 1209600 3600
  example.com has SOA record ns.icann.org. noc.dns.icann.org. 2019121406 7200 3600 3600




SOA fields are  
SOA fields are
  MNAME          Name of the nameservevre that was the source of data for this zone.
                                                                                            here
  RNAME          Mail address of the admin (first . should be treated as the @)
  MNAME          Name of the nameserver that was the source of data for this zone           ns.icann.org
  SERIAL          version of the zone's contents. (Zone transfers preserve this value)
  RNAME          Mail address of the admin (first . should be treated as the @)             noc@dns.icann.org
  REFRESH        interval before the zone should be refreshed.
  SERIAL          version of the zone's contents. (Zone transfers preserve this value)       2019121406 
  RETRY          interval before retrying a failed refresh
  REFRESH        interval before the zone should be refreshed.                             2 hours (7200) 
  EXPIRE          interval after which zone information is not necessarily authoritiative
  RETRY          interval before retrying a failed refresh                                 1 hour  (3600)   
  MINIMUM        Minimum TTL
  EXPIRE          interval after which zone information is not necessarily authoritiative   2 weeks (1209600)
  MINIMUM        Minimum TTL                                                               3600   
(the interaction between EXPIRE, MINIMUM, and TTLs in general are a subject in itself)
(the interaction between EXPIRE, MINIMUM, and TTLs in general are a subject in itself)


SoA also contains a timestamp/counter that changes on any record changes,
SoA also contains a timestamp/counter that changes on any record changes,
making it easier to know when it hasn't or has.
making it easier to know when it hasn't or has.




Line 249: Line 245:
'''Delegation''' refers to using NS records to point at another DNS server to serve a different zone, a different part of your domain.
'''Delegation''' refers to using NS records to point at another DNS server to serve a different zone, a different part of your domain.


Same results, more parts are involved.
Same idea, more parts are involved.


It can make sense to split a domain into distinct responsibilities (distinctly administered zones).
It can make sense to split a domain into distinct responsibilities (distinctly administered zones).




host -t SOA scarfboy.com


scarfboy.com has SOA record dns1.name-services.com. info.name-services.com. 1590860276 172800 900 1814400 3600
scarfboy.com has SOA record dns1.name-services.com. info.name-services.com. 1590860276 172800 900 1814400 3600


host -t NS scarfboy.com
scarfboy.com name server dns2.name-services.com.
scarfboy.com name server dns2.name-services.com.
scarfboy.com name server dns1.name-services.com.
scarfboy.com name server dns1.name-services.com.

Revision as of 03:43, 2 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: