Assuming that you are running separate authoritative and recursive servers this would only be a problem when someone goes to a lame-delegated domain. It is probably also good to note that it is a best practice to separate authoritative and recursive servers. john -----Ursprüngliche Nachricht----- Von: Christopher McCrory [mailto:chrismcc@pricegrabber.com] Gesendet: Friday, January 13, 2006 11:49 AM An: Randy Bush Cc: nanog@merit.edu Betreff: Re: Odd policy question. On Fri, 2006-01-13 at 08:32 -1000, Randy Bush wrote:
Don't forget: www IN CNAME goatse.cx
and don't forget the terminating dot on goatse.cx.
but this did cause me to update those trapper zone files and bump the serials. last time the serials had been bumped since 1995. so you had the suggestion of a decade. mahalo.
Ouch. So you are going to punish the rest of the world for the mistakes of a few people (however annoying it is). /me just cannot imagine explaining this to my mother when she mis-types some URL. Granted that what your (former-) customers did was not any sort of best practice, but I think your "solution" is a little too extreme.
randy -- Christopher McCrory "The^W One of the guys that keeps the servers running"
chrismcc@pricegrabber.com http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works.
--On January 13, 2006 10:09:51 AM -1000 Randy Bush <randy@psg.com> wrote:
it is a best practice to separate authoritative and recursive servers.
why?
Cache poisoning (though this is less likely with more modern bind's and other resolvers) and the age old your view is NOT the same as the world view. IE if you've got a customer who has offsite DNS, but hasn't told you, and you've got authoritative records for his zone, you might be delivering mail locally, or to the wrong place, and it can take a long time to figure this out.
e.g. a small isp has a hundred auth zones (secondaried far away and off-net, of course) and runs cache. why should they separate auth from cache?
randy
-- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
In message <838DBE2645430DF70BAFFC9C@dhcp-2-206.wgops.com>, Michael Loftis writ es:
--On January 13, 2006 10:09:51 AM -1000 Randy Bush <randy@psg.com> wrote:
it is a best practice to separate authoritative and recursive servers.
why?
Cache poisoning (though this is less likely with more modern bind's and other resolvers) and the age old your view is NOT the same as the world view. IE if you've got a customer who has offsite DNS, but hasn't told you, and you've got authoritative records for his zone, you might be delivering mail locally, or to the wrong place, and it can take a long time to figure this out.
Yes. However, that has to be weighed against the greater immunity to cache poisoning in authoritative servers -- if a server *knows* it has the real data, it has much stronger grounds for rejecting nonsense. This is, in fact, one of the tests used. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On 13-Jan-2006, at 15:09, Randy Bush wrote:
it is a best practice to separate authoritative and recursive servers.
why?
Because it prevents stale, authoritative data on your nameservers being returned to intermediate-mode resolvers in the form of apparently authoritative answers, bypassing a valid delegation chain from the root. Stale data might be present due to a customer re-delegating a domain away from your nameservers without telling you, or from the necessity with some registries of having to set up a domain on the auth NS set before domain registration can proceed (or be denied). It might also be introduced deliberately, as described by you in this thread. While periodically checking the zones your authority servers are hosting so that you know when they have been re-delegated away is a good idea, and can reduce the period during which bad answers get sent to clients from a combined auth/res server, segregating the two roles between different nameservers avoids returning *any* stale answers. (Using multiple instances of nameserver daemon running on the same host, bound to different addresses might well be sufficient; you don't necessarily need to add hardware.) This reasoning is orthogonal to the observation that various species of DNS server software (including BIND) have, in the past, featured bugs for which a workaround is to keep authority/cache functions separate. For people using such software, however, this provides additional incentive. Joe
it is a best practice to separate authoritative and recursive servers. why? Because it prevents stale, authoritative data on your nameservers being returned to intermediate-mode resolvers in the form of apparently authoritative answers, bypassing a valid delegation chain from the root.
and thereby hiding the fact that someone has either lame delegated or i have forgotten to remove an auth zone, both cases i want to catch. not a win here. randy
On 13-Jan-2006, at 17:07, Randy Bush wrote:
it is a best practice to separate authoritative and recursive servers. why? Because it prevents stale, authoritative data on your nameservers being returned to intermediate-mode resolvers in the form of apparently authoritative answers, bypassing a valid delegation chain from the root.
and thereby hiding the fact that someone has either lame delegated or i have forgotten to remove an auth zone, both cases i want to catch. not a win here.
If someone has a lame delegation to one of your servers, that's a different problem (and the one that this thread began with). The link between that problem and the one I'm talking about is the decision to treat the former with bogus data as an incentive for the lame delegator to fix their records. The impact of forgetting to remove a zone is greatly reduced if nobody ever has a reason to send a query for that data to your nameserver. To all intents and purposes, hosting random, non- delegated zones on an authority-only server doesn't break anything. However, it's still a good idea to check (e.g. using a script) for forgotten zones, as you say, in the interests of good hygiene. Joe
On Fri, Jan 13, 2006 at 12:07:11PM -1000, Randy Bush wrote:
and thereby hiding the fact that someone has either lame delegated or i have forgotten to remove an auth zone, both cases i want to catch. not a win here.
Responding with stale data is, arguably, more damaging than failing to respond at all. So much so that the SOA expiry field serves to protect us from this threat. So, even though Randy is wrong for wanting to catch misconfigurations by producing incorrect data, I also don't see where Joe is coming from. If I hosted my domain with someone whose server was answering recursive queries, I would probably use a lower value for expiry than I normally would otherwise. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
at root, i am a naggumite. erik nagum was good at describing why broken things should not be patched over. it's better to amplify breakage if that's what it takes to get it fixed asap. yes, this goes against "be liberal in what you accept." tough patooties, that way lies entropic death. an analogous gripe i have is "do-gooder" software, which also applies to configuration and other policies. if do-gooderism 'successfully' compensates for an error, no one notices. when it makes a mistake, everyone screams to the heavens and throws mud. e.g. remember when ejk put in an interceptor cache to give his customers seriously better performance? pain is nature's way of telling us to take our hand off of the stove. randy
On Fri, Jan 13, 2006 at 12:57:22PM -1000, Randy Bush wrote:
at root, i am a naggumite. erik nagum was good at describing why broken things should not be patched over. it's better to amplify breakage if that's what it takes to get it fixed asap.
In this case, the 'break' is only damaging if it is in the query path. If it is not, it ultimately reaches the expiry timer and becomes a non-issue for all involved. Perpetual entropy leading to heat death is not acheived. So, serving a zone that has a very large expiry on a recursive nameserver is, in effect, putting your hand on the burner. Remember I'm on both sides of this fence; Either use a low expiry on zones hosted by recursive nameservers, or use any (probably large) expiry on authoritative-only servers.
an analogous gripe i have is "do-gooder" software, which also applies to configuration and other policies. if do-gooderism 'successfully' compensates for an error, no one notices. when it makes a mistake, everyone screams to the heavens and throws mud. e.g. remember when ejk put in an interceptor cache to give his customers seriously better performance?
Then I guess you won't be a fan of: http://www.ietf.org/internet-drafts/draft-andrews-full-service-resolvers-01....
pain is nature's way of telling us to take our hand off of the stove.
Above is an example of a software engineer (Mr. Andrews) choosing to experience a kind of pain now (the ietf standards process), for others to experience a kind of pain later (those who use rfc1918 space adopting software implementing this), and for the as112 operators to experience less pain until gradually it is retired. Pain in this universe is absolute and eternal. All you can do is choose for whom it is fair to experience how much of it. Something like the Cyclops in Krull. Choose to get left behind in the field to die peacefully, or get crushed in the stone doors saving your friends. The mechanics of the result is unimportant. The choice is. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Let me attempt to bring this back to the policy question. Does someone have the *right* to put one of your IP addresses as an NS record for their domain even if you do not agree? Registrar policies imply that this is so, and has been this way for a long time. A number of years ago (like 8-10 or so) I had a student host a domain on my campus that I rather they not host. When I requested the registrar (or registrar equivalent at the time) to remove the domain, or at least the NS record pointing at my IP address, they refused. Their position was that if I didn't like the domain, I should block access to the IP address. I solved the problem another way... Presumably this would work today, but it takes the effected IP address out of action and Drew's goal, presumably, is to get the IP address back in use without cruft heading its way. Is this a good policy? I can argue it either way myself... -Jeff -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================
On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
Let me attempt to bring this back to the policy question.
Does someone have the *right* to put one of your IP addresses as an NS record for their domain even if you do not agree?
Registrar policies imply that this is so, and has been this way for a long time.
Once upon a time, registrar/er policies did NOT allow this. NSI used to have "GUARDIAN" which controlled who could register domain names listing name servers with your IP addresses. Unfortunately, NSI never completely implemented guardian; and it pretty much completely disappeared after the trademark lawyers took over.
On 13-Jan-2006, at 19:20, Sean Donelan wrote:
On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
Let me attempt to bring this back to the policy question.
Does someone have the *right* to put one of your IP addresses as an NS record for their domain even if you do not agree?
Registrar policies imply that this is so, and has been this way for a long time.
Once upon a time, registrar/er policies did NOT allow this.
That's a little over-broad considering the number of registries there are (and have been, for a long time). I think it's fair to say that even if this was once the case for COM/NET/ORG registries, there are many more registries where this was never close to being true. It seems to me that if someone else chooses to insert 32- or 128-bit integers of their choice into their zone files, then there's properly very little I can or should be able to do about it. But that's just me. Joe
On Fri, 13 Jan 2006, Joe Abley wrote:
It seems to me that if someone else chooses to insert 32- or 128-bit integers of their choice into their zone files, then there's properly very little I can or should be able to do about it. But that's just me.
So I'm sure you would not mind (and would not do anything about it) if .COM operator inserted "* IN A 204.152.184.88" into their zone file? -- William Leibzon Elan Networks william@elan.net
On Fri, 13 Jan 2006, Joe Abley wrote:
It seems to me that if someone else chooses to insert 32- or 128-bit integers of their choice into their zone files, then there's properly very little I can or should be able to do about it. But that's just me.
So I'm sure you would not mind (and would not do anything about it) if .COM operator inserted "* IN A 204.152.184.88" into their zone file?
Yeah, get over it already. -M<
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Abley wrote:
That's a little over-broad considering the number of registries there are (and have been, for a long time). I think it's fair to say that even if this was once the case for COM/NET/ORG registries, there are many more registries where this was never close to being true.
It seems to me that if someone else chooses to insert 32- or 128-bit integers of their choice into their zone files, then there's properly very little I can or should be able to do about it. But that's just me.
You are indeed correct. There is also no good efficient way to know if someone is allowed to use a particular IP address, or will have the right for the life of an extended contract (like a 10 year DNS registration). As an engineer, I believe we would need a protocol that would permit someone to query an IP address to ask what DNS domains it may be an NS for. A simple client server response protocol. Lack of a response would mean "all are welcome here." Sort of the analogue of "robots.txt" for webservers. Then if you wanted to disclaim a domain, you setup a server and notify the registrar of the offending domain. Now as a practical matter, I don't see this happening any time soon. This is simply because this is a lot of mechanism for a problem that I doubt many people have. -Jeff - -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDyXCg8CBzV/QUlSsRAon/AKD6k5Qd1p8jUqGxWEHKYbLec9GgtgCg6bTN GMITL/Fk0qm9sWu4A/M4suA= =88Yt -----END PGP SIGNATURE-----
As an engineer, I believe we would need a protocol that would permit someone to query an IP address to ask what DNS domains it may be an NS for.
this addresses neither the issue of longevity nor that of whether it is authoritative for a particular domain which is proposed to be, or has been, delegated to it. and please note that delegation is not to an ip address, but rather to an fqdn. the only time the two are bound is when a delegatee is within the zone being delegated, so the delegator needs to insert a glue a rr. i run a very small registry for some cctlds. my scripts do specifically check that all servers to which a delegation is proposed are actually serving the zone, and will not delegate if they are not. i also check for 2182 compliance in a crude manner. i also check that the ns rrset held by the servers is that to which delegation is requested. i would gladly re-run the delegation checks against the zone files periodically. but i do not as i don't know what to do when (not if) i find lamers. it seems a bit drastic to just remove delegation. but i know from experience that email to the pocs will get no useful response. randy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Foolish me. Indeed all that is required is a way to detect that the delegation is lame (hopefully in a secure fashion) and remove the lame delegations. Of course that does leave the problem of what to do if all of the delegations are lame, as Randy has alluded to. -Jeff Randy Bush wrote:
As an engineer, I believe we would need a protocol that would permit someone to query an IP address to ask what DNS domains it may be an NS for.
this addresses neither the issue of longevity nor that of whether it is authoritative for a particular domain which is proposed to be, or has been, delegated to it.
and please note that delegation is not to an ip address, but rather to an fqdn. the only time the two are bound is when a delegatee is within the zone being delegated, so the delegator needs to insert a glue a rr.
i run a very small registry for some cctlds. my scripts do specifically check that all servers to which a delegation is proposed are actually serving the zone, and will not delegate if they are not. i also check for 2182 compliance in a crude manner. i also check that the ns rrset held by the servers is that to which delegation is requested.
i would gladly re-run the delegation checks against the zone files periodically. but i do not as i don't know what to do when (not if) i find lamers. it seems a bit drastic to just remove delegation. but i know from experience that email to the pocs will get no useful response.
randy
- -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDyXXb8CBzV/QUlSsRAh97AJ41jM/8ys9Bf3YT/nb7KpnwDuDyygCfXNqc xxfbv+A2ccN9mjLzzLo1N/o= =iKOl -----END PGP SIGNATURE-----
Indeed all that is required is a way to detect that the delegation is lame
for bind vic^H^H^Husers dig +norec zone.name. @delegatee.name. soa to check the ns rrset at the [proposed] delegatee dig +norec zone.name. @delegatee.name. ns on later digs, you can also use the +short option if you don't want to see too much detail. serious pedants can also check for response via tcp, as opposed to just the default udp.
hopefully in a secure fashion
could you amplify?
and remove the lame delegations. Of course that does leave the problem of what to do if all of the delegations are lame
or if a proper subset of the delegations are lame. or if the ns rrset at a delegatee does not match that which was specified to be installed in the delegating zone file. randy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randy Bush wrote:
could you amplify?
If registrars regularly checked for lame delegations (or checked on demand). Then a way to attack a domain would be to forge DNS responses to cause the registrar to remove the domain because it is lame. So DNSSEC would be needed to be sure... -Jeff - -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDyXuu8CBzV/QUlSsRAnAGAJ0WhItRG6VHtHj1QM21NFw+BYxxoQCgyjcy fCQ3B4rYRxosPl40/Z/kSBw= =OMSE -----END PGP SIGNATURE-----
On Sat, Jan 14, 2006 at 05:31:12PM -0500, Jeffrey I. Schiller wrote:
If registrars regularly checked for lame delegations (or checked on demand). Then a way to attack a domain would be to forge DNS responses to cause the registrar to remove the domain because it is lame. So DNSSEC would be needed to be sure...
Something more than merely DNS-SEC. DNS-SEC is about proving zone contents ("object security"). To prove lame delegation you'd need a means to identify the nameserver ("channel security") that's supplying the response. The difference between "this zone contains (or doesn't) an RR" versus "this DNS packet is from the server named George." You could prove inconsistent delegation - that the parent and child differ. But this is not necessarily lame. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On Sat, Jan 14, 2006 at 04:44:02PM -0500, Jeffrey I. Schiller wrote: ...
As an engineer, I believe we would need a protocol that would permit someone to query an IP address to ask what DNS domains it may be an NS for. A simple client server response protocol. Lack of a response would mean "all are welcome here." Sort of the analogue of "robots.txt" for webservers. Then if you wanted to disclaim a domain, you setup a server and notify the registrar of the offending domain.
Now as a practical matter, I don't see this happening any time soon. This is simply because this is a lot of mechanism for a problem that I doubt many people have. ...
On Sat, Jan 14, 2006 at 05:06:20PM -0500, Jeffrey I. Schiller wrote: ...
Foolish me. Indeed all that is required is a way to detect that the delegation is lame (hopefully in a secure fashion) and remove the lame delegations. Of course that does leave the problem of what to do if all of the delegations are lame, as Randy has alluded to. ...
If the intent of the first is to ask, for what zones are you authoritative, with the return being a complete list, then: (a) for many servers this would be a very long list, which may even require TCP/53, which will break some who don't yet accept TCP/53 for queries, which may be seen in the long run as a GOOD thing but in the short run causes problems; and (b) ISTM that a number of people don't WANT to announce every domain that they may be hosting, which is their right, and which may be why there is no such query to date. If the intent of the first is to ask, here is a zone, are you authoritative for it? then just do the query. If it is up and authoritative, it will reply and say so. If it is up and not authoritative, it will either reply and say so, or not reply, depending on its configuration. If it is down, you need to try another server anyway. [Begs the question of what the DNS police do, but ...] The second is a long-acknowledged problem more or less equivalent to the immediately above. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On Sat, 14 Jan 2006 17:06:20 EST, "Jeffrey I. Schiller" said:
Foolish me. Indeed all that is required is a way to detect that the delegation is lame (hopefully in a secure fashion) and remove the lame delegations. Of course that does leave the problem of what to do if all of the delegations are lame, as Randy has alluded to.
If all the delegations are totally lame, then as a *practical* matter the domain is borked anyhow - the only information lost if you simply nuke the whole thing is the SOA (and several incorrect NS records). At one time, I would have suggested trying to contact the entity specified on the SOA. But these days, I'm tempted to say that if they can't get *one* NS pointing at something that will answer, they don't deserve a domain at all... (As noted, there *is* an interesting security exposure if an attacker can force an NS to be reported as lame. On the other hand, the current state of security at most DNS registrars seems to imply that the DNS domain holders don't really care about security anyhow.. ;)
On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
Let me attempt to bring this back to the policy question.
Does someone have the *right* to put one of your IP addresses as an NS record for their domain even if you do not agree?
Registrar policies imply that this is so, and has been this way for a long time.
Once upon a time, registrar/er policies did NOT allow this. NSI used to have "GUARDIAN" which controlled who could register domain names listing name servers with your IP addresses. Unfortunately, NSI never completely implemented guardian; and it pretty much completely disappeared after the trademark lawyers took over.
IIRC, Guardian was fully implemented. Guardian was a method of authentication objects that used pgp to prevent people from modifying objects, and from seeing attributes that were marked private. I have 0 recollection of the object classes, but I remember I had used Guardian extensively on some domains. I'm thinking 97'ish. As far as nameserver modifications for name servers, these were never acked IIRC. As long as you had a valid Netsol handle, you were all set. It was domains that required acks and that was so you had to pay the bill at your hoster or ISP before you moved your services. -M<
On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
Let me attempt to bring this back to the policy question.
Does someone have the *right* to put one of your IP addresses as an NS record for their domain even if you do not agree?
Probably this is a multifaceted question :( So.. If I understand Drew's original question he had a customer (valid paying customer) that signed up for a new domain with $REGISTRAR12 called: "fooble.com". He put in his 2 ip addresses for the 2 servers sitting in Drew's cabinet as NS's (why wouldn't he they were his to use then since he was paying for the service there in Drew's world), he purchased the 10yr plan for the domain. Later his company folded or he moved to another place with another name effectively abandoning the names in place for some unrelated reason(s). Drew is now allocating the 2 ips to a new customer who has setup NS's on the same ips and is now getting 'lame delegation' action from some yokel that walked away from his domain(s) :( So, at the time of the domain registration the registerer had authority to use Drew's ips, now he/she doesn't :( and isn't inn the mood to clean up the 'mess' :(
Registrar policies imply that this is so, and has been this way for a long time.
A number of years ago (like 8-10 or so) I had a student host a domain on my campus that I rather they not host. When I requested the registrar (or registrar equivalent at the time) to remove the domain, or at least the NS record pointing at my IP address, they refused. Their position was that if I didn't like the domain, I should block access to the IP address. I solved the problem another way...
Probably this is a bad solution for Drew, though he MIGHT be able to ID the zones in question: 1) run a NS for a while, log queries for a while 2) sort/uniq queries, make auth responses for the names 3) 'hijack' the domain and send it off to 'other place' via registrar updates. Not always is this feasible :(
On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
Let me attempt to bring this back to the policy question.
Does someone have the *right* to put one of your IP addresses as an NS record for their domain even if you do not agree?
Probably this is a multifaceted question :( So.. If I understand Drew's original question he had a customer (valid paying customer) that signed up for a new domain with $REGISTRAR12 called: "fooble.com". He put in his 2 ip addresses for the 2 servers sitting in Drew's cabinet as NS's (why wouldn't he they were his to use then since he was paying for the service there in Drew's world), he purchased the 10yr plan for the domain.
Later his company folded or he moved to another place with another name effectively abandoning the names in place for some unrelated reason(s). Drew is now allocating the 2 ips to a new customer who has setup NS's on the same ips and is now getting 'lame delegation' action from some yokel that walked away from his domain(s) :(
So, at the time of the domain registration the registerer had authority to use Drew's ips, now he/she doesn't :( and isn't inn the mood to clean up the 'mess' :(
Let's back up to the absolute defintion of the Internet that is still valid to this day: Multiple private networks exchanging traffic. If I get a packet from someone and it crossed my border, IMHO, I own that packet. I either deliver it or drop it. In this case, the case where someone responds with a "The number you have reached.." is a decision to deliver it. There isn't a requirement as to where to deliver it, and if you agree with my interpretation of packet ownership (I think lawyers do..), you'd say that this scenario is reasonable. Note, IANAL, but we've been around enough to make a rough non-legal opinion on this. I think you may have some experience here that I don't since you are at an SP and I'm not so I'd like to hear your thought. -M<
* Jeffrey I. Schiller:
Let me attempt to bring this back to the policy question.
Does someone have the *right* to put one of your IP addresses as an NS record for their domain even if you do not agree?
I don't think it's allowed (and it shouldn't be), but without a cluestick from legal, you won't find anyone who will force the offender to fix it. If this were okay, certainly you wouldn't have objected to someone pointing the A RR of kimble.org to your company web servers, back when Blaster.E was at its height, would you? 8-)
On Fri, Jan 13, 2006 at 10:09:51AM -1000, Randy Bush wrote:
it is a best practice to separate authoritative and recursive servers.
why?
I'm not sure anyone can answer that question. I certainly can't. Not completely, anyway. There are too many variables and motivations. Some remember to say "Read RFC2010 section 2.12." But since that's a document intended specifically for root server operation, it's not as helpful to those of us that don't operate roots. This is about like saying, "Because Vixie wrote it."
e.g. a small isp has a hundred auth zones (secondaried far away and off-net, of course) and runs cache. why should they separate auth from cache?
Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's been discussed already. Note that I can't seem to find the same claim in RFC2870, which obsoletes 2010 (and the direction against recursive service is still there). But in my own personal experience, I can still say without a doubt that combining authoritative and iterative services is a bad idea. Spammers resolve a lot of DNS names. Usually in very short order. As short as they can possibly manage, actually. The bulk of the addresses they have on their lists aren't even registered domain names. Resolving some of these bogus domain names uses substantially more CPU than you might think (spread out over several queries). The result, at a previous place of employ that did not segregate these services, was that our nameservers literally choked to death every time our colocated customers hit us with a spam run. The process' CPU utilization goes to 100%, queries start getting retransmitted, and pretty soon our authoriative queries start getting universally dropped because they're the vast minority of traffic in the system (or the answer comes back so late the client has forgotten it asked the question - has already timed out). So if someone on our network was using our recursive nameservers to resolve targets to spam, people couldn't resolve our names. Even though our servers were geographically diverse, they were all recursive - the miscreant clients would spam them all in harmony. I guess you could say it made it easy to find and shut these miscreants down. But I'd much rather 'spammer detection' be based on something that does not also take my own network down. Now, certainly, designing a network around being impervious to "our clients: the spammers" is not a strong motivation for everyone. But it doesn't take a spammer to see the same series of events unfold. It can just as easily be...say...a lame script in a server...handling error conditions badly by immediately retransmitting the request (we got this too - it flooded our servers with requests for a name within their own domain without any pause inbetween...we kept having to call this customer to reboot his NT box, putting their address space in and out of our ACL's...a significant operational expense, and outages that affected the majority of our customers...for a small colocation customer (not a lot of cash)). So I think this is pretty valid advice for pretty much anyone. It's just a bad idea to expose your authoritative servers to the same problems an iterative resolver is prone to. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
On Fri, Jan 13, 2006 at 01:47:48PM -0800, David W. Hankins wrote:
On Fri, Jan 13, 2006 at 10:09:51AM -1000, Randy Bush wrote:
it is a best practice to separate authoritative and recursive servers.
why?
I'm not sure anyone can answer that question. I certainly can't. Not completely, anyway. There are too many variables and motivations. [...] Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's been discussed already. Note that I can't seem to find the same claim in RFC2870, which obsoletes 2010 (and the direction against recursive service is still there).
In an environment where customers may be able to add zones (such as a web-hosting environment), not separating the two may cause problems when local machines resolve off of the authoritative nameservers. This could be due to someone maliciously or accidentally adding a domain they don't control, or simply to someone setting up their domain prior to changing over the nameservers. w
Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's been discussed already. Note that I can't seem to find the same claim in RFC2870, which obsoletes 2010 (and the direction against recursive service is still there).
despite others saying that 2870 should apply to servers other than root servers, i do not support that. and that leaves aside that some root servers do not follow it very well. randy
On Fri, Jan 13, 2006 at 12:09:51PM -1000, Randy Bush wrote:
Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's been discussed already. Note that I can't seem to find the same claim in RFC2870, which obsoletes 2010 (and the direction against recursive service is still there).
despite others saying that 2870 should apply to servers other than root servers, i do not support that. and that leaves aside that some root servers do not follow it very well.
I have to agree, with the exclusion that some people, having specific requirements that are somewhat similar to root service requirements, find 2870 and 2010 advice useful. My intent here was to point out that all documented reasoning for this practice is unfulfilling. I'm curious if the rest of my response was lost on you due to its verbosity? -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
I'm curious if the rest of my response was lost on you due to its verbosity?
no. it seemed to apply in some cases, and not in others. so it was useful info, but did not seem to be completely relevant to the more unconditional original position "it is a best practice to separate authoritative and recursive servers." randy
On Fri, Jan 13, 2006 at 12:09:51PM -1000, Randy Bush wrote:
Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's been discussed already. Note that I can't seem to find the same claim in RFC2870, which obsoletes 2010 (and the direction against recursive service is still there).
despite others saying that 2870 should apply to servers other than root servers, i do not support that. and that leaves aside that some root servers do not follow it very well.
randy
RFC 2870 was crafted at a time when the machines hosting the root zone also hosted several -large- TLD zones. Anycast was not widely used when this document was written. RFC 2010 did indicate that requirements would likely change in future, while RFC 2870 reinforced the then status quo. Perhaps the most fatal mistake of RFC 2870 was the ambigious treatment of the service provisioning as distinctly different than protecting the availability of the (single?) instance of the hardware that provides that service. Given the changed nature of the publication platform for the root zone, (no big TLDs hosted there anymore) and the widescale use of anycast in the root, while not with many TLDs - it is clear to me that RFC 2870 applicability is oriented more toward TLD operations. For these and a few other reasons, no root server operator that i am aware of (save ICANN) actually tries to follow RFC 2870... Several try and follow RFC 2010 still ... despite the I[E/V]TF's marking of "obsolete" on RFC 2010. That said, there might be a replacement for both offered up - if time allows. --bill
On Fri, 13 Jan 2006, Randy Bush wrote:
it is a best practice to separate authoritative and recursive servers.
why?
e.g. a small isp has a hundred auth zones (secondaried far away and off-net, of course) and runs cache. why should they separate auth from cache?
I absolutely hate it when we run into an ISP that does this. We often have customers who are moving form some piss poor ISP and we "rescue" them. Then we find out that none of ISP A's customers (often including the customer who is moving their hosting) can get to the new site. Similarly we have occasionally seen customers who moved their hosting from us and we were still delivering mail locally. In order for the root servers to do their job the two really need to be separate. Chris -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc ~ www.hubris.net ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Fri, 13 Jan 2006, Randy Bush wrote:
it is a best practice to separate authoritative and recursive servers. e.g. a small isp has a hundred auth zones (secondaried far away and off-net, of course) and runs cache. why should they separate auth from cache?
and it means that you can use software that specializes in the authoritative or recursive operation or if you use the same software optimise your configuration for either operation. Even if they decide to combine the two and ignore other problems people have listed then from the customer end they should be seperate so that it is an option to split them in the future. Migrating 10% of your customers base who have the "wrong" name servers hardcoded in their machines is *never* fun. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
* Randy Bush:
it is a best practice to separate authoritative and recursive servers.
why?
e.g. a small isp has a hundred auth zones (secondaried far away and off-net, of course) and runs cache. why should they separate auth from cache?
Some registrars require that you begin to serve the domain before it's actually delegated to you. If you don't run a split setup, it might happen that you hijack someone else's domain. For example, some ISPs already serve .EU domains on their resolvers, although they haven't been delegated to them yet. A unified setup also means that customers can hijack domains (intentionally or not) if your registratry checks go wrong. And you don't notice if the delegation goes astray for some reason. The upside of a unified setup is that DNS continues to work even if you're disconnected from the Internet. It is somewhat easier to configure. And you aren't subject to DNS spoofing attacks for your own domains.
participants (18)
-
bmanning＠vacation.karoshi.com -
Chris Owen -
Christopher L. Morrow -
David W. Hankins -
Florian Weimer -
Jeffrey I. Schiller -
Joe Abley -
John van Oppen -
Joseph S D Yao -
Martin Hannigan -
Michael Loftis -
Randy Bush -
Sean Donelan -
Simon Lyall -
Steven M. Bellovin -
Valdis.Kletnieks＠vt.edu -
William Yardley -
william(at)elan.net