I thought I understood but from recent contexts here it is clear that I
do not.
I thought a resolver was code in your local machine that provide
hostname (FQDN?), given address; or address, given host name (with
assists to build FQDN).
And I thought a "server" was a separate program, might be on the same
machine, might be on another machine (might be on the local net, might
be distant) that the resolver code called for information that was not
in local cache.
Just what is the straight scoop?
No doubt Olafur will beat me up yet again for not having written the
DNS lexicon years ago, but:
- A "resolver" is something that implements the "resolver" (ie,
client) role in the DNS protocol. It might be a stub resolver, the
client side of a recursive nameserver, a pure iterative resolver,
....
The defining characteristic is that it send queries (QR=0) and
receives responses (QR=1).
- A "name sever" is something that implements the "nameserver" (ie,
server) role in the DNS protocol. It might be an authoritative
nameserver, the server side of a recursive nameserver, ....
The defining characteristic is that it receives queries (QR=0) and
sends responses (QR=1).
Clear enough?
Mapping protocol definitions onto the plethora of terms used by
operators in the field is left as an exercise for the reader, no
sarcasm intended. DNS is an old protocol, there are an awful lot of
people who think they understand it, and each of those people has
their own set of terms that they're comfortable using. The
definitions above are what I rammed through the IETF during several
rounds of standards writing, but I would be the first to admit that
not everybody uses the terms the same way as I do.
A "resolver" is basically a client.
There's two types of resolvers - recursive resolvers (that look after
doing the full resolution themselves - starting at the root servers
and working down), and "stub resolvers" which are only smart enough
pass the entire request onto another server to handle.
On most system, the "code in your local machine" will be a stub
resolver. That's why you need to configure it to point to another
server that looks after the actual recursion for you.
The "DNS Server" running at your ISP that your stub resolver connects
to is acting as both a server (to accept requests from your client),
and as a resolver (to actually resolve those requests), and almost
certainly also as a cache for results. For simplicity, many people
simply refer to them as Resolvers, whilst others call them Recursive
servers or Caching servers.
The server actually answering the requests for your domain is an
Authoritative Server. An Authorative-only server doesn't ever act as a
client, so it isn't a resolver.
It is possibly to run both Authoritative and Recursive server on the
same IP, but it's generally not recommended for many reasons (the most
simple being that of stale data if your server is no longer the
correct nameserver for a domain, but it's still configured to be
authoritative for that domain).
Scott.
I thought I understood but from recent contexts here it is clear that I
do not.
I thought a resolver was code in your local machine that provide
hostname (FQDN?), given address; or address, given host name (with
assists to build FQDN).
And I thought a "server" was a separate program, might be on the same
machine, might be on another machine (might be on the local net, might
be distant) that the resolver code called for information that was not
in local cache.
Just what is the straight scoop?
No doubt Olafur will beat me up yet again for not having written the
DNS lexicon years ago, but:
- A "resolver" is something that implements the "resolver" (ie,
client) role in the DNS protocol. It might be a stub resolver, the
client side of a recursive nameserver, a pure iterative resolver,
....
The defining characteristic is that it send queries (QR=0) and
receives responses (QR=1).
- A "name sever" is something that implements the "nameserver" (ie,
server) role in the DNS protocol. It might be an authoritative
nameserver, the server side of a recursive nameserver, ....
The defining characteristic is that it receives queries (QR=0) and
sends responses (QR=1).
Clear enough?
Yes--tracks with what I thought, pretty much--I was missing the
clientness of the resolver code to go with the serverness of the server.
Mapping protocol definitions onto the plethora of terms used by
operators in the field is left as an exercise for the reader, no
sarcasm intended. DNS is an old protocol, there are an awful lot of
people who think they understand it,
I am one of those is sure he understands it--which belief crumbles when
I try to explain it to somebody else.
and each of those people has
their own set of terms that they're comfortable using. The
definitions above are what I rammed through the IETF during several
rounds of standards writing, but I would be the first to admit that
not everybody uses the terms the same way as I do.
DNS arcana is one of the things that somebody should document on the
internet-history list while there are still people around who can do so
with some authority.
Thanks.
A "resolver" is basically a client.
There's two types of resolvers - recursive resolvers (that look after
doing the full resolution themselves - starting at the root servers
and working down), and "stub resolvers" which are only smart enough
pass the entire request onto another server to handle.
On most system, the "code in your local machine" will be a stub
resolver. That's why you need to configure it to point to another
server that looks after the actual recursion for you.
That is another piece that I had glossed over--the "client" side of a
server.
The "DNS Server" running at your ISP that your stub resolver connects
to is acting as both a server (to accept requests from your client),
and as a resolver (to actually resolve those requests), and almost
certainly also as a cache for results. For simplicity, many people
simply refer to them as Resolvers, whilst others call them Recursive
servers or Caching servers.
Calling any form of server a "resolver" seems new to me--or my lack of
understanding is older that I like to admit.
The server actually answering the requests for your domain is an
Authoritative Server. An Authorative-only server doesn't ever act as a
client, so it isn't a resolver.
It is possibly to run both Authoritative and Recursive server on the
same IP, but it's generally not recommended for many reasons (the most
simple being that of stale data if your server is no longer the
correct nameserver for a domain, but it's still configured to be
authoritative for that domain).
Seems like TTL management would take care of that but I think the issues
of recursion are now different from the safe world I thought I lived in
20 years ago.
Thanks.
TTL's play no part in how any Authoritative server answers a request.
Consider what happens if your DNS server was authoritative for
example.com, and the .com nameservers pointed to you for that domain.
Your customer who owns the domain then changes the delegation to
another provider (and/or the domain expires, etc) but doesn't tell
you.
At this point, your server is still answering all requests for
example.com - because that's what authoritative servers do. It won't
check to make sure that the domain is still delegated to it, and doing
so would make no sense in a generic sense (eg, it might be an internal
only domain, or testing a new domain that hasn't yet been delegated to
you, etc).
If one of your clients queries the server - in the context of it being
a recursive server - it will respond with your view of the world for
example.com, which is incorrect.
If the server was configured as authoritative only, and another server
(or a different IP on the same server) was acting as the recursive
server then your authoritative server will still return the incorrect
answers if asked - but nobody will ever ask it for a domain that isn't
correctly delegated to it.
There are (poor) solutions to this, such as regular checks that all
domains you're serving are actually delegated to you - but simply
separating the functions is a far better solution.
Scott.
It is possibly to run both Authoritative and Recursive server on the
same IP, but it's generally not recommended for many reasons (the most
simple being that of stale data if your server is no longer the
correct nameserver for a domain, but it's still configured to be
authoritative for that domain).
Seems like TTL management would take care of that but I think the issues
of recursion are now different from the safe world I thought I lived in
20 years ago.
TTL's play no part in how any Authoritative server answers a request.
I understand that--but it the TTL is being managed correctly the server
answering authoritatively ought to stop doing so when the TTL runs out,
since it will not have had its authority renewed.
Consider what happens if your DNS server was authoritative for
example.com, and the .com nameservers pointed to you for that domain.
Your customer who owns the domain then changes the delegation to
another provider (and/or the domain expires, etc) but doesn't tell
you.
At this point, your server is still answering all requests for
example.com - because that's what authoritative servers do. It won't
check to make sure that the domain is still delegated to it, and doing
so would make no sense in a generic sense (eg, it might be an internal
only domain, or testing a new domain that hasn't yet been delegated to
you, etc).
The glue and all of that stuff won't expire at TTL=0?
I'll have to study that a bit.
Seems like the zone file shold have been replaced to reflect the
authority change.
I understand that--but it the TTL is being managed correctly the server
answering authoritatively ought to stop doing so when the TTL runs out,
since it will not have had its authority renewed.
That's not how things work. If you configure bind to be authoratative for example.com, your zone file has a serial number, and various other SOA fields, some of which tell caching servers how long you'd like them to cache hits and misses. Some will totally ignore those TTLs, but that's an entirely different rant.
Now consider example.com moves and the gtld-servers point NS for it at my server. I set it up differently than you did (different NS records, different A record IPs, etc.). Unless you remove example.com from your bind config, your server will still think it's authoratative for it. If your server is a locally used caching server and an authoratative server (as used to be quite common, esp. for smaller networks), the clients using your DNS server will still see the old example.com records from your outdated authoratative data.
The glue and all of that stuff won't expire at TTL=0?
No. Authoratative data on your server (a locally configured zone) doesn't require glue.
Seems like the zone file shold have been replaced to reflect the
authority change.
Should have been removed...but if everything that should happen did happen, things would be so much simpler.
I understand that--but it the TTL is being managed correctly the server
answering authoritatively ought to stop doing so when the TTL runs out,
since it will not have had its authority renewed.
The TTL can never "run out" on an authoritative nameserver, the
TTL given for a query response is always the full TTL of the RR
that a dns admin populated the zone with.
The only way an authoritative nameserver should expire and become
non-authoritative (without administrative action) for a record is the
case where it is a slave server, and it fails to receive updates
from the master for an entire zone before the "EXPIRE" period
defined in the zone's SOA (in seconds) elapses.
After the expire value, then, the zone is no longer authoritative on the slave.
This is normally set to a very large number, such as 604800 or 2419200
(7 or 30 days, respectively).
The glue and all of that stuff won't expire at TTL=0?
I'll have to study that a bit.
Which type of glue are you referring to?
TTL only indicates the expiration time of resolver cached information
after the resolver has already returned the complete response.
Additional sections provided expire from resolver cache, when TTL of
the RR in the additional secretion is decremented from zero.
SOAs always have a TTL of zero, anyways.
A TTL of zero just prohibits caching (and some unruly resolvers or
web browsers violate the standard ignore the prohibition against
caching).. DNS pinning, and they call this breach of standard a
"security" feature.
Also, BIND implements the EXPIRE value in the SOA.
But other DNS server software applications widely ignore this value,
and the zone stays authoritative on all servers, no matter how much
time elapses between updates (in that case).
The glue and all of that stuff won't expire at TTL=0?
No. Authoratative data on your server (a locally configured zone) doesn't
require glue.
I really should have scrapped that reply and started over--by the time I
got to this part I realized that authority delegation is a matter of
what is in the zone file, not what has been learned.
Seems like the zone file shold have been replaced to reflect the
authority change.
Should have been removed...but if everything that should happen did
happen, things would be so much simpler.
Trudat.
And if there are loops in the zone transfer graph slaves can stay
alive even if they are checking the serial of the master to see if
they need to expire the zone.
Mark