Will reverting DNS wildcard have any adverse affects?
I keep trying to think of how this discussion could be operationally relevant. The only thing I could come up with is: Will reverting back to the proper NXDOMAIN break anything? I have only seen inconveniences on my network since they changed, though I know some had it worse than I did. For the benefit of other NANOG readers, make sure reverting back won't cause more headaches on your network. Gerald Coon - How are ya? Never been better, ... Just once I'd like to be better.
Well, considering that large numbers of community members here installed the BIND patch (and patches for other vendors software) the day it was released, I think we're just fine with this. :-) On Fri, Oct 03, 2003 at 06:03:16PM -0400, Gerald wrote:
I keep trying to think of how this discussion could be operationally relevant. The only thing I could come up with is:
Will reverting back to the proper NXDOMAIN break anything?
I have only seen inconveniences on my network since they changed, though I know some had it worse than I did. For the benefit of other NANOG readers, make sure reverting back won't cause more headaches on your network.
Gerald Coon
- How are ya? Never been better, ... Just once I'd like to be better.
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
On Fri, 3 Oct 2003, Wayne E. Bouchard wrote:
Well, considering that large numbers of community members here installed the BIND patch (and patches for other vendors software) the day it was released, I think we're just fine with this. :-)
I am personally thrilled they are reverting. I also hope ICANN succeeds in politely (without the need for legal actions) convince them that this is a bad idea. I have confidence in the bind patch not breaking bind when Verisign reverts back, but there were some pretty rash suggestions when the sitefinder service first came online. (Paul, bind won't break when this goes back to normal will it?) I just wanted to point out if anyone did something other than just patching bind and moving on, consider the repercussions of Verisign reverting or you might have your weekend plans averted to undo your changes. Gerald Coon
--On Friday, October 03, 2003 7:36 PM -0400 Gerald <gcoon@inch.com> wrote:
I just wanted to point out if anyone did something other than just patching bind and moving on, consider the repercussions of Verisign reverting or you might have your weekend plans averted to undo your changes.
Gerald Coon
I only changed the service that was most drastically affected, my anti-spam relays. I put in a HACK() that restored the "sender domain must exist" behavior to sendmail, when a sender domain resolved to the SiteFinder address. I figured my measures ought to affect as little as possible, and address only real operational problems that the wildcards caused. I am optimistic that this is the last time we'll see any wildcards in any gTLDs. --- "The avalanche has already begun. It is too late for the pebbles to vote." -- Kosh
I have confidence in the bind patch not breaking bind when Verisign reverts back, but there were some pretty rash suggestions when the sitefinder service first came online. (Paul, bind won't break when this goes back to normal will it?)
ask yourself how many DNS admins are going to go pull out the "-delegation" stanzas from their configs? Or that will use them to lie about other delegations that use wildcards as long as that code is still available? ... someone should write up a FAQ now, describing how to troubleshoot DNS anomolies that will arise as a result of this code being in the wild. IMHO, its going to be a -long- time before this "feature" is eradicated from the deployed base. :(
Gerald Coon
--bill
On Fri, Oct 03, 2003 at 05:34:07PM -0700, bmanning@karoshi.com wrote:
ask yourself how many DNS admins are going to go pull out the "-delegation" stanzas from their configs? Or that will use them to lie about other delegations that use wildcards as long as that code is still available? ...
And what possible problems are you expecting with leaving zone "com" { type delegation-only; }; zone "net" { type delegation-only; }; in the configuration? They should be delegation-only in any case, shouldn't they? p. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)
On Sat, Oct 04, 2003 at 03:48:52PM +0200, Piotr KUCHARSKI wrote:
On Fri, Oct 03, 2003 at 05:34:07PM -0700, bmanning@karoshi.com wrote:
ask yourself how many DNS admins are going to go pull out the "-delegation" stanzas from their configs? Or that will use them to lie about other delegations that use wildcards as long as that code is still available? ...
And what possible problems are you expecting with leaving zone "com" { type delegation-only; }; zone "net" { type delegation-only; }; in the configuration?
They should be delegation-only in any case, shouldn't they?
At some point in the future you might think back on this as someone who said, "What possible problems would there be in hard-coding this list of bogon filters? 69.0.0.0/8 should be reserved, shouldn't it?" -rob
On Sat, Oct 04, 2003 at 10:39:33AM -0400, Rob Payne wrote:
At some point in the future you might think back on this as someone who said, "What possible problems would there be in hard-coding this list of bogon filters? 69.0.0.0/8 should be reserved, shouldn't it?"
IP space might have been given out sooner or later. Probability that "com" and "net" users will agree on having wildcard there (like in "museum") is in a close proximity to zero. p. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)
On Fri, Oct 03, 2003 at 05:34:07PM -0700, bmanning@karoshi.com wrote:
ask yourself how many DNS admins are going to go pull out the "-delegation" stanzas from their configs? Or that will use them to lie about other delegations that use wildcards as long as that code is still available? ...
And what possible problems are you expecting with leaving zone "com" { type delegation-only; }; zone "net" { type delegation-only; }; in the configuration?
They should be delegation-only in any case, shouldn't they?
well, thats up to the zone admin. :) my concern is mostly along the lines of folks who will do things like: zone "waw.pl" { type delegation-only; }; to random zones that they think -SHOULD- be delegation-only, regardless of what the zone admin specifies.
p.
-- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)
And what possible problems are you expecting with leaving zone "com" { type delegation-only; }; zone "net" { type delegation-only; }; in the configuration?
They should be delegation-only in any case, shouldn't they?
that was the basis of the enhanced version of the feature, which is spelled "root-delegation-only". non-delegation data in root or toplevel domains is possibly useful (like www.$TLD) but not necessary (an NS can be put in to achieve the same effect with an extra "hop".)
well, thats up to the zone admin. :) my concern is mostly along the lines of folks who will do things like:
zone "waw.pl" { type delegation-only; };
to random zones that they think -SHOULD- be delegation-only, regardless of what the zone admin specifies.
"and remember, kids, all power tools can kill." -- Paul Vixie
On Sat, Oct 04, 2003 at 04:24:18PM +0000, Paul Vixie wrote:
zone "com" { type delegation-only; }; zone "net" { type delegation-only; }; They should be delegation-only in any case, shouldn't they? that was the basis of the enhanced version of the feature, which is spelled "root-delegation-only".
Paul, I would not call "root-delegation-only" an enhancement. With "type delegation-only", you had to specifically name these and only these zones you wanted restricted. With the latter, you need to be alert all the time, keep an eye on all TLDs, whether they are legally using delegations. If I am not mistaken, "exclude" statement to this option had four revisions already. p. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)
Paul, I would not call "root-delegation-only" an enhancement.
it's an enhancement in the sense that it's more complicated and it's more code and it came later in response to complaints about the earlier feature.
With "type delegation-only", you had to specifically name these and only these zones you wanted restricted. With the latter, you need to be alert all the time, keep an eye on all TLDs, whether they are legally using delegations. If I am not mistaken, "exclude" statement to this option had four revisions already.
Four revisions in the first two days, none since. -- Paul Vixie
On Sat, Oct 04, 2003 at 08:29:45AM -0700, bmanning@karoshi.com wrote:
zone "com" { type delegation-only; }; zone "net" { type delegation-only; }; well, thats up to the zone admin. :)
Everything is. :)
my concern is mostly along the lines of folks who will do things like: zone "waw.pl" { type delegation-only; }; to random zones that they think -SHOULD- be delegation-only, regardless of what the zone admin specifies.
So you are questioning the "type delegation-only" functionality? Then it's a wrong address, stupidity will always be the biggest problem in the universe. However, Verisign hijacking "com" and "net" made few things clear. Most important: these domains are public, not theirs, hence they should not do arbitrary changes to them. Marking "com" and "net" as delegation-only is not harming anything. (At least until ICANN changes its mind.) p. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)
On Sat, Oct 04, 2003 at 08:29:45AM -0700, bmanning@karoshi.com wrote:
zone "com" { type delegation-only; }; zone "net" { type delegation-only; }; well, thats up to the zone admin. :)
Everything is. :)
glad you agree.
my concern is mostly along the lines of folks who will do things like: zone "waw.pl" { type delegation-only; }; to random zones that they think -SHOULD- be delegation-only, regardless of what the zone admin specifies.
So you are questioning the "type delegation-only" functionality? Then it's a wrong address, stupidity will always be the biggest problem in the universe.
in a word, YES. and there have been/are lots of folks who fall into the trap of either "stupidity" or ignorance (more likely) who will do things simply because is was in some script or manual w/o questioning -why-. These types of folks can be reasoned with, its just that there are so many of them... :) More worrysome are those who are disgruntled or are malicious and will code things up to be disruptive by choice. while BIND is open-source and any knuckledragging code jock can "haq the source" to do this, ISC is acting as arm manufacture and dealer, handing out easy to use code that allows local admins to lie to themselves and those that use their servers about what the zone admin indicates is correct for the zone. (and yes, I have a bias here... :)
However, Verisign hijacking "com" and "net" made few things clear. Most important: these domains are public, not theirs, hence they should not
that is not clear to me. I'd like to argue that -ALL- delegations are made in the public interest and are not "owned" by anyone. You and others are trying to claim that some delegations are "public" and some are not. I'd really like to see the legal basis for making such a distinction.
do arbitrary changes to them. Marking "com" and "net" as delegation-only is not harming anything. (At least until ICANN changes its mind.)
perhaps not. I remain unconvinced.
p.
-- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)
On Sat, Oct 04, 2003 at 12:39:21PM -0700, bmanning@karoshi.com wrote:
So you are questioning the "type delegation-only" functionality? Then it's a wrong address, stupidity will always be the biggest problem in the universe. in a word, YES. and there have been/are lots of folks who fall into the trap of either "stupidity" or ignorance (more likely) who will do things simply because is was in some script or manual w/o questioning -why-.
But delegation-only and root-delegation-only are not in the script or FAQ. They are in the manual, like all the rest of the options, but with no attitude.
These types of folks can be reasoned with, its just that there are so many of them... :) [...] while BIND is open-source and any knuckledragging code jock can "haq the source" to do this, ISC is acting as arm manufacture and dealer, handing out easy to use code that allows local admins to lie to themselves and those that use their servers about what the zone admin indicates is correct for the zone. (and yes, I have a bias here... :)
ISC had put so many controls in bind, including acls, allow-transfers, views... they all allow local admins to lie to themselves and those that use their servers. It's no reason for not liking the flexibility in bind.
However, Verisign hijacking "com" and "net" made few things clear. Most important: these domains are public, not theirs, hence they should not that is not clear to me. I'd like to argue that -ALL- delegations are made in the public interest and are not "owned" by anyone.
Delegations themselves are usually owned by those who paid for them. :) Arbitrary entries/changes by the TLD domain holder in the unpaid[1] space should not be allowed without prior consent of all involved parties.
You and others are trying to claim that some delegations are "public" and some are not. I'd really like to see the legal basis for making such a distinction.
IMO all TLDs are public. Like country names. You cannot own them and do whatever you want with them. Some methods of operating them are questionable, not the fact that they are public.
Marking "com" and "net" as delegation-only is not harming anything. (At least until ICANN changes its mind.) perhaps not. I remain unconvinced.
Remember, though, that these two configuration options are not default (and should (and will) never be). And I will probably withdraw them from my configuration once Verisign stops using wildcard in com/net. If there are no further problems with them, noone will use these options; why bother, when things are running as they should? p. [1] "Unpaid" as in net/com; other tlds may have different requirements for having domains registered. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)
* chopin@sgh.waw.pl (Piotr KUCHARSKI) [Sat 04 Oct 2003, 20:51 CEST]: [..]
do arbitrary changes to them. Marking "com" and "net" as delegation-only is not harming anything. (At least until ICANN changes its mind.)
According to this mail: http://gnso.icann.org/mailing-lists/archives/registrars/msg00532.html ... apparently it breaks IDN resolution. Does anybody have the definite word on that? Regards, -- Niels.
At 23:40 05/10/2003, Niels Bakker wrote:
do arbitrary changes to them. Marking "com" and "net" as delegation-only is not harming anything. (At least until ICANN changes its mind.)
According to this mail: http://gnso.icann.org/mailing-lists/archives/registrars/msg00532.html ... apparently it breaks IDN resolution. Does anybody have the definite word on that?
It would seem to do so, yes - removal of the wildcard would also imply that Verisign's IDN stopgap (between applications which use the xn-- encoding and applications which do 8-bit dns) will now break. -- Joel Rowbottom, http://www.centralnic.com - CTO and self-confessed Unix geek <t> +44 (0)20 7751 9000 <f> +44 (0)20 7736 9253 <e> joel@centralnic.com # Note: Contents may not necessarily represent the opinions of CentralNic.
On Mon, Oct 06, 2003 at 12:40:42AM +0200, Niels Bakker wrote:
do arbitrary changes to them. Marking "com" and "net" as delegation-only is not harming anything. (At least until ICANN changes its mind.) According to this mail: http://gnso.icann.org/mailing-lists/archives/registrars/msg00532.html ... apparently it breaks IDN resolution. Does anybody have the definite word on that?
Hm. And how would it suppose to break IDN resolution? Client encodes the hostname, then asks the DNS about already encoded name. So the bind receives the request about, say, "xn--szkoagwnahandlowa-lyb21mca.pl". How would that fail with "delegation-only"? p. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master. -- Commissioner Pravin Lal http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)
At 15:52 06/10/2003, Piotr KUCHARSKI wrote:
do arbitrary changes to them. Marking "com" and "net" as delegation-only is not harming anything. (At least until ICANN changes its mind.) According to this mail: http://gnso.icann.org/mailing-lists/archives/registrars/msg00532.html ... apparently it breaks IDN resolution. Does anybody have the definite word on that?
Hm. And how would it suppose to break IDN resolution? Client encodes the hostname, then asks the DNS about already encoded name. So the bind receives the request about, say, "xn--szkoagwnahandlowa-lyb21mca.pl".
I don't think Niels was referring to the "proper" IDN solution, but more the stopgap implementation which Verisign pushed into service. It actually resembles Sitefinder in many ways :/ j x -- Joel Rowbottom, http://www.centralnic.com - CTO and self-confessed Unix geek <t> +44 (0)20 7751 9000 <f> +44 (0)20 7736 9253 <e> joel@centralnic.com # Note: Contents may not necessarily represent the opinions of CentralNic.
* joel@jml.net (Joel Rowbottom) [Mon 06 Oct 2003, 22:34 CEST]:
At 15:52 06/10/2003, Piotr KUCHARSKI wrote:
do arbitrary changes to them. Marking "com" and "net" as delegation-only is not harming anything. (At least until ICANN changes its mind.) According to this mail: http://gnso.icann.org/mailing-lists/archives/registrars/msg00532.html ... apparently it breaks IDN resolution. Does anybody have the definite word on that? Hm. And how would it suppose to break IDN resolution? Client encodes the hostname, then asks the DNS about already encoded name. So the bind receives the request about, say, "xn--szkoagwnahandlowa-lyb21mca.pl". I don't think Niels was referring to the "proper" IDN solution, but more the stopgap implementation which Verisign pushed into service. It actually resembles Sitefinder in many ways :/
I only referred to the archived registrars mailing list posting; I'm not following IDN much as, even though it's nice to see actual work being done in that area, it does smell of VeriSign landgrab. I'm interested in what has also broken due to the rash wildcard addition by Verisign. If anybody has any more technical information on this, please step forward. Regards, -- Niels.
participants (9)
-
bmanning＠karoshi.com -
Gerald -
Joel Rowbottom -
Mike Batchelor -
Niels Bakker -
Paul Vixie -
Piotr KUCHARSKI -
Rob Payne -
Wayne E. Bouchard