Time out for a terminology check--"resolver" vs "server".
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? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
At Sun, 14 Feb 2010 18:02:48 -0600, Laurence F Sheldon, Jr wrote:
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. On Sun, Feb 14, 2010 at 4:02 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
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? -- "Government big enough to supply everything you need is big enough to take everything you have."
Remember: The Ark was built by amateurs, the Titanic by professionals.
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On 2/14/2010 6:21 PM, Scott Howard wrote:
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. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Sun, Feb 14, 2010 at 5:19 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
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. 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.
On 2/14/2010 7:48 PM, Scott Howard wrote:
On Sun, Feb 14, 2010 at 5:19 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
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. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Sun, 14 Feb 2010, Larry Sheldon wrote:
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. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 2/14/2010 8:14 PM, Jon Lewis wrote:
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. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Sun, Feb 14, 2010 at 7:55 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
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). -- -J
In message <6eb799ab1002141824s652c4f31od02cb750912a064b@mail.gmail.com>, James Hess writes:
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).
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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (6)
-
James Hess -
Jon Lewis -
Larry Sheldon -
Mark Andrews -
Rob Austein -
Scott Howard