more on lame-delegation.org, seems to waste IP space and DNS
so i've been doing a bit more research on this. NSI has *.lame-delegation.org which is used on zones where selected or all NS are not valid for a zone. some zones have a lame-delegation.org NS listed *AND* a NS that is answering for the zone. most zones have all NS's listed as lame-delegation.org Big deal you say, who cares.... The side affect is that a good chuck of glue records are listed in the the gTLD DNS servers with NS's and IP's that are basicly invalid. In looking at a single /19 used by Rackspace.com, there are 559 NS's listed using IP's from that /19. Of those 559 NS's over 20 are IP's tagged as *.lame-delegation.org. What happens if someone sets up a service on those IP's and a "quasi" lame zone gets a flood of traffic?? That poor customer is going to see a flood of DNS traffic. Hosting providers may not be aware that THEIR IP space is being "renamed" and listed for things they don't have control over. My thoughts are that if a registry as a NS that is not proper for a zone, that it should be REMOVE from the zones NS set. If there are no valid NS's for a zone, then the registry should REMOVE the zone from the DNS. Otherwise the registry zones will just grow with random glue The other registries and registrars are doing similar things, but different names....
If what they are doing is not ok, what would you propose? Leaving dns hanging when domain is expired is not right either. Deleting domains when some other domain is using dns host in it, will cause problems for registry. They are doing best they can - fast rename and delete domain, then slow notification, change of dns for other domains and delete the glue. The way it should work is to have central notification system for all top-level domains and country domains - if dns host is to be deleted, system notifies all zone operators, they check if they have any domains using those dns hosts and delete hosts from under those domains. Once ack is received from everybody (or notification time expires), the host glue is deleted. The problem is that this deletion process takes longer then standard domain deletion and for all registries the time and procedures to delete the domains are different that is why central system does not seem to work. On Mon, 16 Jun 2003, John Brown wrote:
so i've been doing a bit more research on this.
NSI has *.lame-delegation.org which is used on zones where selected or all NS are not valid for a zone.
some zones have a lame-delegation.org NS listed *AND* a NS that is answering for the zone.
most zones have all NS's listed as lame-delegation.org
Big deal you say, who cares....
The side affect is that a good chuck of glue records are listed in the the gTLD DNS servers with NS's and IP's that are basicly invalid.
In looking at a single /19 used by Rackspace.com, there are 559 NS's listed using IP's from that /19.
Of those 559 NS's over 20 are IP's tagged as *.lame-delegation.org.
What happens if someone sets up a service on those IP's and a "quasi" lame zone gets a flood of traffic??
That poor customer is going to see a flood of DNS traffic.
Hosting providers may not be aware that THEIR IP space is being "renamed" and listed for things they don't have control over.
My thoughts are that if a registry as a NS that is not proper for a zone, that it should be REMOVE from the zones NS set.
If there are no valid NS's for a zone, then the registry should REMOVE the zone from the DNS.
Otherwise the registry zones will just grow with random glue
The other registries and registrars are doing similar things, but different names....
if a domain expires it shouldn't be in the TLD zone, and thats a seperate issue. I'm talking about delegations in the gTLD zone that reference name servers that are INVALID. These *.lame-delegation.org machines are NOT under the authority of NSI, the service provider who's IP NSI has tagged is having to transit traffic with no customer relationship with the domain holder or NSI. When you have broken DNS (ergo MS-Redmond) I can see machines attempting to query forever. These lame-delegation.org. machines don't answer NXDOMAIN, SERVFAIL or anything else. They just time out. given (dig below) that this zone has TWO NS's listed with the .NET server and that BOTH are pointing to 'lame-delegation.org' servers, it would seem to me this violates the registry and registrar agreements. If it was me, I'd remove the delegation from the .NET server and place a tag in the "whois data" saying that valid NS's need to be added. I would also recommend that NSI (and others) configure a set of machines that answer NXDOMAIN for these LAME zones, place these on systems NSI has control over. columbia# dig @a.gtld-servers.net artists-quote.net ns ; <<>> DiG 8.3 <<>> @a.gtld-servers.net artists-quote.net ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; artists-quote.net, type = NS, class = IN ;; ANSWER SECTION: artists-quote.net. 2D IN NS lame10294.lame-delegation.org. artists-quote.net. 2D IN NS lame10295.lame-delegation.org. On Mon, Jun 16, 2003 at 07:05:17PM -0700, william@elan.net wrote:
If what they are doing is not ok, what would you propose?
Leaving dns hanging when domain is expired is not right either. Deleting domains when some other domain is using dns host in it, will cause problems for registry. They are doing best they can - fast rename and delete domain, then slow notification, change of dns for other domains and delete the glue.
The way it should work is to have central notification system for all top-level domains and country domains - if dns host is to be deleted, system notifies all zone operators, they check if they have any domains using those dns hosts and delete hosts from under those domains. Once ack is received from everybody (or notification time expires), the host glue is deleted. The problem is that this deletion process takes longer then standard domain deletion and for all registries the time and procedures to delete the domains are different that is why central system does not seem to work.
On Mon, 16 Jun 2003, John Brown wrote:
so i've been doing a bit more research on this.
NSI has *.lame-delegation.org which is used on zones where selected or all NS are not valid for a zone.
some zones have a lame-delegation.org NS listed *AND* a NS that is answering for the zone.
most zones have all NS's listed as lame-delegation.org
Big deal you say, who cares....
The side affect is that a good chuck of glue records are listed in the the gTLD DNS servers with NS's and IP's that are basicly invalid.
In looking at a single /19 used by Rackspace.com, there are 559 NS's listed using IP's from that /19.
Of those 559 NS's over 20 are IP's tagged as *.lame-delegation.org.
What happens if someone sets up a service on those IP's and a "quasi" lame zone gets a flood of traffic??
That poor customer is going to see a flood of DNS traffic.
Hosting providers may not be aware that THEIR IP space is being "renamed" and listed for things they don't have control over.
My thoughts are that if a registry as a NS that is not proper for a zone, that it should be REMOVE from the zones NS set.
If there are no valid NS's for a zone, then the registry should REMOVE the zone from the DNS.
Otherwise the registry zones will just grow with random glue
The other registries and registrars are doing similar things, but different names....
In a message written on Mon, Jun 16, 2003 at 07:05:17PM -0700, william@elan.net wrote:
If what they are doing is not ok, what would you propose?
This is a bit of a sideways step, but... I'm sure a lot of people would like to be able to register a zone and not point it at any nameservers, and not even have it appear in the top level zone files. Many people "sit" on a zone for many reasons, and in most cases having to point them at a nameserver just to register it is pointless and stupid. If a domain could exist in that state, then these domains could just have the lame name servers removed from their records, possibly existing with no nameservers, until the owner pointed them at the right place. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
For all top-level domains you can register a domain and not have any name servers specified for it. In whois it'll say exactly that - "no nameservers". I'd be very much against removing these domains from root zones entirely, but I maybe biased since I use these zone files for my own software. On Tue, 17 Jun 2003, Leo Bicknell wrote:
In a message written on Mon, Jun 16, 2003 at 07:05:17PM -0700, william@elan.net wrote:
If what they are doing is not ok, what would you propose?
This is a bit of a sideways step, but...
I'm sure a lot of people would like to be able to register a zone and not point it at any nameservers, and not even have it appear in the top level zone files. Many people "sit" on a zone for many reasons, and in most cases having to point them at a nameserver just to register it is pointless and stupid.
If a domain could exist in that state, then these domains could just have the lame name servers removed from their records, possibly existing with no nameservers, until the owner pointed them at the right place.
On Tue, Jun 17, 2003 at 05:03:07AM -0700, william@elan.net wrote:
For all top-level domains you can register a domain and not have any name servers specified for it. In whois it'll say exactly that - "no nameservers".
Not correct, registrar and registry agreements require at least two name servers.
I'd be very much against removing these domains from root zones entirely, but I maybe biased since I use these zone files for my own software.
The 'root zones' have nothing to do with what I'm talking about.
On Tue, 17 Jun 2003, Leo Bicknell wrote:
In a message written on Mon, Jun 16, 2003 at 07:05:17PM -0700, william@elan.net wrote:
If what they are doing is not ok, what would you propose?
This is a bit of a sideways step, but...
I'm sure a lot of people would like to be able to register a zone and not point it at any nameservers, and not even have it appear in the top level zone files. Many people "sit" on a zone for many reasons, and in most cases having to point them at a nameserver just to register it is pointless and stupid.
If a domain could exist in that state, then these domains could just have the lame name servers removed from their records, possibly existing with no nameservers, until the owner pointed them at the right place.
For all top-level domains you can register a domain and not have any name servers specified for it. In whois it'll say exactly that - "no nameservers".
Not correct, registrar and registry agreements require at least two name servers. Unless I'm mistaken (which is doubtfull considering how often I see whois results with "no nameserver" in crsnic whois) this is not the case. In fact I remember hearing about removing requirement to have two nameservers back in 1999 when things where still being handled only by NSI and ICANN was non-existant.
--- William Leibzon Elan Communications Inc. william@elan.net
On Tuesday, Jun 17, 2003, at 12:18 Canada/Eastern, John Brown wrote:
On Tue, Jun 17, 2003 at 05:03:07AM -0700, william@elan.net wrote:
For all top-level domains you can register a domain and not have any name servers specified for it. In whois it'll say exactly that - "no nameservers".
Not correct, registrar and registry agreements require at least two name servers.
Any registry that supports RRP (Verisign Registry, PIR) or even slightly old drafts of EPP must allow domains to be registered with no host objects, since there is no other way to allow domains with subordinate nameservers to be created in the registry (the required procedure is create-domain-with-no-nameservers, create-subordinate-hosts, add-nameservers-to-domain). Domains with no nameservers can't appear in the corresponding registry zone, since no delegation is possible. Note this is registry functionality made available to registrars, and does not necessarily imply functionality available to registrants. Joe
* bicknell@ufp.org (Leo Bicknell) [Tue 17 Jun 2003, 16:34 CEST]:
I'm sure a lot of people would like to be able to register a zone and not point it at any nameservers, and not even have it appear in the top level zone files. Many people "sit" on a zone for many reasons, and in most cases having to point them at a nameserver just to register it is pointless and stupid.
FWIW, at least the .ch TLD registrar allows reservation of domains without putting them in the zone file. The only disadvantage I see with this is that my preferred way of checking whether a domain is available for registration (`dig ns dom.ain.') no longer works. The .nl registrar used to differentiate between "reserved" domains (words that were considered too generic when those weren't allowed to be registered as domains) by returning NOERROR and no data instead of NXDOMAIN. -- Niels. -- The generation of random numbers is Too important to leave to chance
quoted-printable returned as a favor to all those who can't live w/o it. such zone exist and process were(are?) in place to create delegations like this.
--pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
In a message written on Mon, Jun 16, 2003 at 07:05:17PM -0700, william@elan= .net wrote:
If what they are doing is not ok, what would you propose?
This is a bit of a sideways step, but...
I'm sure a lot of people would like to be able to register a zone and not point it at any nameservers, and not even have it appear in the top level zone files. Many people "sit" on a zone for many reasons, and in most cases having to point them at a nameserver just to register it is pointless and stupid.
If a domain could exist in that state, then these domains could just have the lame name servers removed from their records, possibly existing with no nameservers, until the owner pointed them at the right place.
--=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
--pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+7yZxNh6mMG5yMTYRAmBFAJ9rsJjvhOM/3JEv5SuTec2jw9cotACfUlhy qU4SOQhoVDb32ZK2XTXOh4A= =eVZj -----END PGP SIGNATURE-----
--pf9I7BMVVzbSWLtt--
participants (6)
-
bmanning＠karoshi.com -
Joe Abley -
John Brown -
Leo Bicknell -
Niels Bakker -
william＠elan.net