Re: large organization nameservers sending icmp packets to dns servers.
On Mon, 6 Aug 2007, Drew Weaver wrote: Is it a fairly normal practice for large companies such as Yahoo! And Mozilla to send icmp/ping packets to DNS servers? If so, why? And a related question would be from a service provider standpoint is there any reason to deny ICMP/PING packets to name servers within your organization? If someone else mentioned this I didn't see it, so I think it's worthwhile to point out that in the case of Yahoo! at least the pinging isn't done by nsX.yahoo.com, but rather it's done by Akamai after you get to the point in the chain where the "real" answer is going to come from one of their servers. Someone else already did point out that in spite of the existence of outliers, the shape of the bell-shaped curve remains the same, and if this method didn't actually work then it wouldn't be in such widespread use. hth, Doug -- If you're never wrong, you're not trying hard enough
Re: IPv6 PI block is announced - update your filters 2620:0000::/23
Gert Doering wrote: > Does the policy really permit /40.../47 assignments? http://www.arin.net/registration/guidelines/ipv6_assignment.html#step2 -- If you're never wrong, you're not trying hard enough
Re: managing mycompany.{all iso TLD + icann TLD) ?
Jay R. Ashworth wrote: > Someone's possesion of a domain name contining a string you have a > trademark on *in one specific line of business* *does not constitute an > infringement of your trademark*. > > Unless they *use it* *in conjunction with a product or service name* > *in the appropriate line of business* *in a jurisdiction where you hold > trademark rights*, they're not infringing you, and registering the > string in 435 TLD's just to make sure they can't is the worst kind of > stupid. If I can borrow from Randy, I encourage my competitors (and more importantly the competitors of my clients) to operate in the manner you describe. Doug -- If you're never wrong, you're not trying hard enough
Re: managing mycompany.{all iso TLD + icann TLD) ?
David Ulevitch wrote: > > > On Jul 24, 2006, at 6:18 AM, Jim Mercer wrote: > >> the company i'm working for has a growing list of domains for the company >> and its trademarks. >> >> are there resellers out there that have agreements with _most_ TLD >> registries? >> >> i realize that i won't likely find a single reseller for all the >> TLD's, but >> i'd like to switch from using 10 baskets to 2 or three. > > There are companies that specialize in this: > http://www.markmonitor.com/ I have worked with the folks at MarkMonitor, and their acquisition alldomains, and know a few of them personally. If you're looking for the kind of "soup to nuts" domain management program that the OP described, I would recommend them highly. hth, Doug -- If you're never wrong, you're not trying hard enough
Re: MEDIA: ICANN rejects .xxx domain
Fred Baker wrote: > Now, as to ccTLDs vs gTLDs, if anyone wants to eliminate one or the > other they get my vote. The political reality is that ccTLDs will never go away. The business reality is that gTLDs (at least the majority of the ones we have now) will never go away. So, can we move on to something *slightly* less pointless, like moving .gov and .mil under .us where they belong? :) Doug -- If you're never wrong, you're not trying hard enough
Re: Equal access to content
Sean Donelan wrote: > Should content suppliers be required to provide equal access to all > networks? Or can content suppliers enter into exclusive contracts? SBC and Yahoo! have already answered this question (for example). I also think that most people on this list will remember the early days of broadband suppliers like RoadRunner who tried to build a "we are mostly local content, plus some Internet access" model which the customers hated, and they (for the most part) eventually abandoned altogether. Even AOL was forced by market pressure to provide real Internet to its customers. Doug .oO(Glad I don't own any SBC stock ...) -- If you're never wrong, you're not trying hard enough
Re: IANA Blackhole Servers Ill?
Crist Clark wrote:
>
> We got some very weird compaints about applications "hanging." Tracked
> it down to reverse lookups timing out. Reverse lookups to RFC1918 space.
> Looks like the IANA blackhole servers for RFC1918 are not well?
>From my location (Comcast cable modem in LA) I can see the IANA servers, and
they are answering queries.
> (Of course, the fix is to claim authority for the RFC1918 space you are
> using in your own DNS servers.)
It's arguably a good idea for resolving name servers to be authoritative for
all the 1918 space, as well as the zones recommended in RFC 1912
(ftp://ftp.rfc-editor.org/in-notes/rfc1912.txt). You can set up an empty
zone file (just SOA and NS), and do something like this:
zone "10.in-addr.arpa" { type master; file "master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; };
Any more specific zones that you add for space that you're actually using
will be effective for those blocks instead of the more generic definitions
(at least in modern versions of BIND).
hth,
Doug
New IANA IPv6 allocation for RIPE NCC (2A01:0000::/23)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /23 block to RIPE NCC: 2A01:::/23RIPE NCC For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-unicast-address-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFC11HbwtDPyTesBYwRAhQTAJ9zNSoAfkApywj1GnaV4mQRx7yNRQCfVWQW Up/pBqgT/VgF5tZn0X/E1zE= =BWO4 -END PGP SIGNATURE-
New IANA IPv6 allocation for APNIC (2400:2000::/19)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /19 block to APNIC: ~ 2400:2000::/19APNIC For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-unicast-address-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCzvPowtDPyTesBYwRAlciAKCeR86MJyCmtjbP/MxviXIM6yT8ugCeL9XJ vPlR8n8sUyDaEEnsXIFm5zE= =/Kd+ -END PGP SIGNATURE-
New IANA IPv4 allocation for RIPE NCC (89/8, 90/8, 91/8)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following three (3) IPv4 /8 blocks to RIPE NCC: 89/8 90/8 91/8 For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCxEwgwtDPyTesBYwRAjajAJ9bo5grWwRRsKakb4mgn9Mh2/GL7QCgheO6 Xirb1dsrMytiQeUa8GZKE4Y= =sDQ0 -END PGP SIGNATURE-
New IANA IPv4 allocations to ARIN (74/8, 75/8, 76/8) and LACNIC (189/8, 190/8)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that on 17 June 2005 the IANA has allocated the following two (2) IPv4 /8 blocks to LACNIC: 189/8, 190/8 and three (3) IPv4 /8 blocks to ARIN: 74/8, 75/8, 76/8 For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCs2C8wtDPyTesBYwRAscHAKCQEWrG96z/1FmhZWl1Mrt13hzBngCeNUCF SldR9Wbc4WTNoLoI7dJlKJc= =cq00 -END PGP SIGNATURE-
New block of AS Numbers to APNIC (37888-38911)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following block of AS Numbers to APNIC: 37888-38911 For a full list of IANA AS Number allocations please see <http://www.iana.org/assignments/as-numbers> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCqNmowtDPyTesBYwRAq87AJ9vZylxVXcni50h2sKEebZLDpa1jQCcDU4a Uiryl1vEehaC/xj6rby0te0= =Q3MX -END PGP SIGNATURE-
New IANA IPv6 allocation for APNIC (2400::/19)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that on 20 May 2005 the IANA allocated the following one (1) IPv6 /19 block to APNIC: ~ 2400:::/19 APNIC For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-unicast-address-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCkm/+wtDPyTesBYwRAoF2AKCauGLNaAEcyvyCEH5S2ev1KuDH/ACfakit cJ3TQ6O4MiYq9mb2L/JaAC0= =mJiE -END PGP SIGNATURE-
Re: Paul Wilson and Geoff Huston of APNIC on IP address allocation ITU v/s ICANN
Stephane Bortzmeyer wrote: So, like ICANN, governements and big corporations are represented at the ITU. Like ICANN, ordinary users are excluded. I think groups like the Non-Commercial Users Constituency (http://gnso.icann.org/non-commercial/) and the At Large Advisory Committee (http://alac.icann.org/) would disagree with that perspective. :) Doug -- If you're never wrong, you're not trying hard enough
New IPv6 allocations from IANA to RIPE NCC (2a00::/21) and ARIN (2600::/22, 2604::/22, 2608::/22, 260c::/22)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /21 block to RIPE NCC: 2A00:::/21RIPE NCC And, the IANA has allocated the following four (4) IPv6 /22 blocks to ARIN: 2600:::/22ARIN 2604:::/22ARIN 2608:::/22ARIN 260C:::/22ARIN For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-unicast-address-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD4DBQFCZWp/wtDPyTesBYwRAqWyAKCbj584cn15sQ4h67durCWPS/denQCVFSOM c0CXWpEMK4kmc6GcN6ak4Q== =Tjnd -END PGP SIGNATURE-
Re: Auerbach Accuses ICANN Board of Dereliction of Duty on IP Allocation
[EMAIL PROTECTED] wrote: Whether Karl is in fact right or a raving net.loon, there is indeed something very wrong with the process if he's 25% of the input. It may be useful to keep in mind that this is the tail end of a long process that we're talking about here. There was already a lot of discussion about this in the RIR regional forums when the policy was being developed, so far from being symptomatic of a problem I think that the lack of controversy here is a good sign that the system works. FWIW, Doug -- If you're never wrong, you're not trying hard enough
Re: New IANA IPv4 allocation to AfriNIC (41/8)
Jeroen Massar wrote: On Tue, 2005-04-12 at 23:42 -0300, Doug Barton wrote: This is to inform you that the IANA has allocated the following one (1) IPv4 /8 block to AfriNIC: 41/8 AfriNIC Would you (read: IANA) also be so kind and give them a nice chunk out of: http://www.iana.org/assignments/ipv6-unicast-address-assignments There is already a /23 in 2001::/16 that has AfriNIC's name on it, you'll be hearing more about that tomorr... errr... later today. Allocations of larger IPv6 blocks are still handled on a case by case basis until there is a global IPv6 allocation policy developed in the manner described by the new ASO MOU. A new draft of such a policy will be discussed at ARIN's meeting in Orlando next week. Btw, is there going to be an LACNIC-alike system for transfering RIPE/ARIN resources to AfriNIC? I wouldn't characterize it exactly that way, but resources that have been held in trust and/or managed by the other RIRs in anticipation of an African RIR will be transferred. The details of those arrangements are primarily administrative matters, and while ICANN is happy to assist if necessary, we have confidence that the RIRs will work this out in due time. Regards, Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority
New block of AS Numbers to AfriNIC (36864 - 37887)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following block of AS Numbers to AfriNIC: 36864 - 37887 For a full list of IANA AS Number allocations please see <http://www.iana.org/assignments/as-numbers> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCXIgUwtDPyTesBYwRApSgAJ9u404MINfsM2XdmK0sXfGGHXcaPgCeOQ8h QKw9DITHv3urKt1fmm0SFs8= =SIAW -END PGP SIGNATURE-
New IANA IPv4 allocation to AfriNIC (41/8)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv4 /8 block to AfriNIC: 41/8 AfriNIC For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> This is the first allocation to AfriNIC after their recent recognition as a Regional Internet Registry. The ICANN staff would like to offer its congratulations to AfriNIC for this significant achievement. - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCXIcvwtDPyTesBYwRAi3eAJ9/+Dr9XZcD4xEeEhGv8f51YjYaEACgib9Z HBliA/KP+Xsbe1Bp/poOJfM= =+Z/c -END PGP SIGNATURE-
New IANA IPv4 allocation for ARIN (73/8)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA allocated the following IPv4 /8 block to ARIN on 30 March 2005: 73/8ARIN For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCXE12wtDPyTesBYwRAkjnAKCSGtF+Th8C8O5TBvGVrEB2KjxEaACglcmP 51kn9rKZz8D34Dq5GJ18sBo= =xgtM -END PGP SIGNATURE-
Re: ICANN on the panix.com theft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Galvin wrote: > > > --On Saturday, March 26, 2005 4:58 PM -0500 David Lesher <[EMAIL PROTECTED]> > wrote: > >> >> ICANN Blames Melbourne IT for Panix Domain Hijacking > > > Unfortunately, the agenda for the next ICANN meeting: > ><http://www.icann.org/meetings/mardelplata/> > > Still does not yet show that the SSAC > ><http://www.icann.org/committees/security/> > > Will be having a public meeting on Tuesday, from 6:30-7:30pm, during > which it will present its preliminary results and recommendations from > its review of the incident. That agenda has now been updated. As I understand it, the final version of the agenda had to wait on some coordination with the local host, which has now been completed. FYI, Doug - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCSgrKwtDPyTesBYwRArktAJ9KI2XQIHpBc53M2pr6Pmw642pJqwCcDC2c P4zfNeqK6ny4o6mfzDXQDlQ= =sFS8 -END PGP SIGNATURE-
New IANA IPv4 allocation for APNIC (124/8, 125/8, 126/8)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following three (3) IPv4 /8 blocks to APNIC: 124/8 APNIC 125/8 APNIC 126/8 APNIC For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB+UfKwtDPyTesBYwRAiFLAJwPunYfqYEZzru+Zhpo3Tzf0kF75QCgoN14 OXCHaZBmTrtvRdSRjxt9VZQ= =KaeV -END PGP SIGNATURE-
New IANA IPv6 allocation for RIPE NCC (2003:0000::/18)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /18 block to RIPE NCC: 2003:::/18 RIPE NCC 12 Jan 05 For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-tla-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB5aL5wtDPyTesBYwRAm4zAJ9a/3st27eUsCQeD2WKIoL8QVNA5gCfWc9F eHLYn34mS0qj3IhwU2woMLU= =qS1+ -END PGP SIGNATURE-
New IANA IPv6 allocation for RIPE NCC (2001:4C00::/23)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /23 block to the RIPE NCC: 2001:4C00::/23RIPE NCC For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-tla-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBwNAhyIakK9Wy8PsRAtXyAJ4t1M6cQC/137a8+e5Zhv3juJUTOwCg5Mq0 6tyjLHMDph1d+vRKSgBtJio= =miYo -END PGP SIGNATURE-
New IANA IPv6 allocation for APNIC (2001:8000::/23 - 2001:AE00::/23)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is to inform you that the IANA has allocated the following twenty-four (24) IPv6 /23s blocks to APNIC: 2001:8000::/23 APNIC 2001:8200::/23 APNIC 2001:8400::/23 APNIC 2001:8600::/23 APNIC 2001:8800::/23 APNIC 2001:8A00::/23 APNIC 2001:8C00::/23 APNIC 2001:8E00::/23 APNIC 2001:9000::/23 APNIC 2001:9200::/23 APNIC 2001:9400::/23 APNIC 2001:9600::/23 APNIC 2001:9800::/23 APNIC 2001:9A00::/23 APNIC 2001:9C00::/23 APNIC 2001:9E00::/23 APNIC 2001:A000::/23 APNIC 2001:A200::/23 APNIC 2001:A400::/23 APNIC 2001:A600::/23 APNIC 2001:A800::/23 APNIC 2001:AA00::/23 APNIC 2001:AC00::/23 APNIC 2001:AE00::/23 APNIC For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-tla-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBq7nryIakK9Wy8PsRAkXKAKDt5e51TRqDOP04sSgvN76NyrIlWACg5hcV e+9tLEhXv99J5t9l9eY2kMg= =SODE -END PGP SIGNATURE-
New IANA IPv6 allocation for RIPE NCC (2001:5000::/20)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following eight (8) IPv6 /23 blocks to the RIPE NCC: 2001:5000::/23RIPE NCC 2001:5200::/23RIPE NCC 2001:5400::/23RIPE NCC 2001:5600::/23RIPE NCC 2001:5800::/23RIPE NCC 2001:5A00::/23RIPE NCC 2001:5C00::/23RIPE NCC 2001:5E00::/23RIPE NCC For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-tla-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBQMQKwtDPyTesBYwRApYAAJ9Hcp2S2wPrTHIh4pGE3jGR3YHdKwCdG2KB 8U+gB3PS1sW5nrAtkW8hllY= =4TnN -END PGP SIGNATURE-
New IANA IPv6 allocation for ARIN (2001:4800::/23)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /23 block to ARIN: 2001:4800::/23ARIN For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-tla-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBKm8PwtDPyTesBYwRAnfHAKCBxmaON7MF9r+Ko43yshPM9ybNggCeLTDQ Ac2NQab3SdbNosQcnQ+Y4Vo= =MPa3 -END PGP SIGNATURE-
Re: New IANA IPv6 allocation for RIPE NCC (2001:4600::/23)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Aug 2004, Doug Barton wrote: For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> This would have been more useful if I had copied and pasted from the right message, sorry: For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-tla-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBIVj+wtDPyTesBYwRArXsAKCVVDWLBGMxRUVDqPPTDN7HrAdKeQCfX70A 6MFNTYaOQaugHyEtODpzPi4= =BcfX -END PGP SIGNATURE-
New IANA IPv6 allocation for RIPE NCC (2001:4600::/23)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /23 block to the RIPE NCC: 2001:4600::/23RIPE NCC For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> - -- Doug Barton General Manager, Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBIVY/wtDPyTesBYwRAi8/AJ44TNst0AM4xqOHDXZcmo+rCqOP1QCbBR0g zhtl1VzZ7/2W7luxyN/b/NU= =5pBC -END PGP SIGNATURE-
New IANA IPv4 allocation for ARIN (71/8, 72/8)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following two (2) IPv4 /8 blocks to ARIN: 071/8 Aug 04 ARIN(whois.arin.net) 072/8 Aug 04 ARIN(whois.arin.net) For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> - -- Doug Barton General Manager, Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBDuAYwtDPyTesBYwRAq9aAJ99l6Pib51qvGRgYuPam+jFv/TBOgCeNcFI d0lRn5E983SPgV/Ag9xnAZM= =qqA2 -END PGP SIGNATURE-
New IANA IPv6 Allocations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is to inform you that the IANA has allocated the following three (3) IPv6 /23 blocks to RIPE NCC, ARIN, and APNIC respectively: 2001:4000::/23RIPE NCC Jun 04 2001:4200::/23ARIN Jun 04 2001:4400::/23APNIC Jun 04 In addition to the above allocations, it should be noted that ARIN has returned their most recently allocated IPv6 block, 2001:3C00::/23 to the IANA, which has marked that block and the one immediately following it "reserved" in anticipation of a possible future allocation to the RIPE NCC. IANA would like to formally thank ARIN for their willingness to operate in the best interests of the Internet community. For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-tla-assignments> At their request, this message is being sent to the following communities: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Regards, Doug - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAykOQwtDPyTesBYwRAmPrAJ9yz+QyWv8FvE9bA79N9O8H8MFb0ACeKlTE hrFfWUtIQLL4VixUtQ9psM0= =E2aq -END PGP SIGNATURE-
New block of AS Numbers to ARIN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is to inform you that the IANA has allocated the following block of AS Numbers to ARIN: 32768 - 33791 For a full list of IANA AS Number allocations please see http://www.iana.org/assignments/as-numbers - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAt8hiwtDPyTesBYwRAljZAKCG30/XaGZxXaX3INTIN7FflvLAlgCgijFb Vl7S7lKJJ+RilDhyr792HFg= =G6z6 -END PGP SIGNATURE-
New IPv6 Allocation to ARIN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is to inform you that the IANA has allocated the following IPv6 /23 block to ARIN: 2001:3C00::/23 ARIN For a full list of IANA IPv6 allocations please see: http://www.iana.org/assignments/ipv6-tla-assignments - -- Doug Barton General Manager, Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFArmPzwtDPyTesBYwRAlMcAJ0QbmVVh32h0UX7CLfeum6I8qGB+wCfRmOi XD6hR9kQpwWB/3sIMqrLhLk= =RHGH -END PGP SIGNATURE-
Re: New IANA allocations to RIPE NCC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 7 May 2004, william(at)elan.net wrote: > Also FYI - I noticed this message was actually signed (PGP) and I believe > that may be first iana announcement message that was, thank you !!! Certainly not the first, but I agree with the community feedback we've received that PGP signing these messages is useful, although I also agree with Pekka that its usefulness needs to be taken in context. > P.S. Of course its also notable that it says "Version: PGP 8.0 - not > licensed for commercial use". Why is that notable? > I kind of wonder if use by IANA or ICANN is considered commercial or > not... But I guess if organization is dedicated to being > non-commercial that might be OK, but is ICANN really like that? ICANN is organized as a not for profit corporation. As for the question of the size of the allocation, it's not appropriate for IANA to comment on how RIPE plans to use the block, but I will say that they justified their request appropriately. The allocation was done in /23 chunks because that's what the current allocation model is. The RIRs, IANA, and the IAB are currently in discussion about what a more rational IPv6 allocation policy should look like, given that we're moving out of the "experimental" phase of deployment. Last but not least, the question of why we allocate IPv4 in /8 chunks is answered by the new global IPv4 allocation policy, agreed to by IANA and passed in the policy forum stage by all 4 RIRs. You can find a copy at http://www.ripe.net/ripe/draft-documents/iana-rir-allocation-policies.html. It will move out of "draft" status once it's fully ratified by the ICANN ASO, but IANA has agreed to use the policy now as a sign of good faith in our dealings with the RIRs. Hope this helps, Doug - -- Doug Barton General Manager, Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAnLSWwtDPyTesBYwRAne4AJ0Rvv5NldNaQqkQk8Erc2AoRfLDhgCeIRyi qoCOvUJRzE77u4WSqkNr5AI= =vmPW -END PGP SIGNATURE-
Re: updated root hints file (fwd)
On Sun, 1 Feb 2004, Randy Bush wrote: > > let's face it. we should be looking at the front page > of the <http://iana.org/> site to find root hints. there > we find <http://www.iana.org/domain-names.htm>, which seems > to be missing a link to the signed root hints. > > iana, could you please fix that? thanks. Okey dokey. :) I took this suggestion, and a few other recent suggestions regarding the usefulness of the site and added a "most popular links" page, which includes the root.hints stuff. I also added a couple of new links to the home page, and deleted some less frequently used ones. Please take a look at http://www.iana.org/ and let me know what you think. We have more improvements planned for the IANA site down the road as resources become available, but in the short term I think these changes will help. Doug -- Doug Barton General Manager, Internet Assigned Numbers Authority
Re: updated root hints file
Randy Bush wrote: > let's face it. we should be looking at the front page > of the <http://iana.org/> site to find root hints. there > we find <http://www.iana.org/domain-names.htm>, which seems > to be missing a link to the signed root hints. > > iana, could you please fix that? thanks. Good idea. I had that in mind along with some other changes for later this quarter, but given the amount of attention this topic is generating, I'll try to get something up asap. Thanks, Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority
Re: example.com/net/org DNS records
On Mon, 5 Jan 2004, Roger Marquis wrote: > On Mon, 5 Jan 2004, Doug Barton wrote: > > > > > There's already been a lot of discussion about why this is a good thing, > > so I won't reiterate it all. > > Thanks Doug. Are those discussions available on the net? If so > could you post the URL? The discussion I'm referring to is the one that happened on the NANOG list subsequent to your post. Doug -- Doug Barton General Manager, Internet Assigned Numbers Authority
Re: example.com/net/org DNS records
On Sun, 4 Jan 2004, Roger Marquis wrote:
>
> Does anyone know why IANA has assigned NS and A records to the
> example.{com,org,net,...} domains? They even put up a website
> at the IP explaining RFC 2606.
>
> * Why did they assign NSs and a valid IP to these invalid domains?
There's already been a lot of discussion about why this is a good thing,
so I won't reiterate it all. That web site gets roughly 5 million hits a
week, so we believe that it's definitely providing a valuable
educational service to the internet community.
> * Are they breaking the RFC by doing this?
We don't believe we are, and certainly wouldn't intentionally take any
action that violates the RFC's. The IANA is entrusted with safeguarding
a lot of internet resources, and it's a responsibility that we take very
seriously.
> * Are they breaking anti-UCE filters by doing this? (yes)
This is an unfortunate side effect, but we believe that the user
education benefits are worth the cost.
> * Are they harvesting URLs and referrers?
We log the "standard" stuff that just about any other web site would,
including URI's, referers, etc. As someone else pointed out,
"harvesting" the URI's won't really provide us any benefit. As for the
referers, if the community finds this problematic, I would have no
problem turning it off. We don't release the data, and currently we're
not doing anything with it other than logging it, so we wouldn't miss it
if it went away. :)
Hopefully this information is useful. If you have any further questions,
please feel free to contact me.
Doug
--
Doug Barton
General Manager, Internet Assigned Numbers Authority
Re: RR/ATDN NYC
On Sun, 23 Nov 2003, Will Yardley wrote: > > On Sun, Nov 23, 2003 at 11:25:22PM -0500, Charles Sprickman wrote: > > > The only two folks that I was not able to reach were Yahoo! and SBCGlobal. > > I've had good success reaching Yahoo based on the contact information in > the Arin whois; called the number on there, and got through to a real > person fairly quickly. This was a month ago. That's good to hear! Over the last 2.5 years I've put a lot of work into making sure our whois stuff is up to date. I still have a few things to punch up before I fully transition to my new position, but if you notice something that's out of date, please feel free to let me know. > I'm told that you can also email ynoc-request at yahoo dot com (for > normal NOC type queries only, I assume). Correct. They do a great job of routing requests to the proper channels, so if it's actually something significant, don't hesitate to mail them. Doug -- Doug Barton, Yahoo! DNS Administration and Development "You like pain? Try wearing a corset!" Keira Knightley as Elizabeth Swann, in "Pirates Of The Caribbean: The Curse of the Black Pearl"
ICANN Secsac message to the board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recommendations Regarding VeriSign's Introduction of Wild Card Response to Uninstantiated Domains within COM and NET http://www.icann.org/correspondence/secsac-to-board-22sep03.htm Several members of this community responded to my request for input on this topic, and your very helpful suggestions were incorporated in the final product. On behalf of the Committee, I'd like to thank you for these contributions, and encourage you to continue sending comments and suggestions regarding operational or security issues. Doug Barton -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/b6gQyIakK9Wy8PsRAivkAJwLQGFRFSWqklE0q0qVzYk3J+ivWwCfc/AX 8Vvn+ABkkw2MsUK3za0fQ4Q= =cvJc -END PGP SIGNATURE-
Re: Wildcards: ICANN and IAB posted their commentaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 Sep 2003 [EMAIL PROTECTED] wrote: > http://www.icann.org/announcements/advisory-19sep03.htm Folks, In regards to the statement above, the Security and Stability Advisory Committee is sincerely interested in your feedback regarding this issue. We are currently working on a report that details the impacts of wildcards at the TLD level, and elsewhere as appropriate. I would like to request that you restrict your comments to actual operational issues. That will help ensure that they get due consideration. We're most interested in issues related to things that worked before, but don't now; and particularly interested in non-obvious cases. Of course, if you have other points of interest on this topic, we're all ears. The e-mail address for your feedback is [EMAIL PROTECTED] Doug -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/a9//yIakK9Wy8PsRAkQqAJwPXQzltTL4Kp4NRfSJR56gwBbdgQCg+WOc Py1DIywm8FKhA3Q/v4XxrmY= =jdSM -END PGP SIGNATURE-
Re: BIND 9 (Re: ISC Patches)
On Wed, 17 Sep 2003, Todd Vierling wrote: > (Although I noticed that NetBSD's pkgsrc version of bind9 doesn't install > the HTML docs, which are now required in order to understand named.conf > changes. I'll probably submit a change request for that.) FreeBSD's does. :) Doug (aka [EMAIL PROTECTED]) -- "You're walkin' the wire, pain and desire. Looking for love in between." - The Eagles, "Victim of Love"
Re: Important changes to the .org tld today.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm speaking officially only for myself here, although my opinion is informed by the fire drill at work today. :) On Fri, 5 Sep 2003, Rodney Joffe wrote: > During the root zone (.) update later today, specifically with root > zone serial number 2003090501, the entries for .org will me modified. Rodney, Thanks for giving us this update, any notice is better than none. :) However, I have two requests that I'd like you (and anyone with similar responsibilities elsewhere) to take into account for next time. 1. A little _more_ advanced notice would be appreciated. At least 24 hours, preferably more. 2. Making the actual change on a day other than Friday would be fabulous, so I don't have to change critical systems right before the weekend. Fortunately, this particular change didn't cause a lot of hair pulling, but in general it would be nice if folks would take these two points into consideration. I'm sure I'm not the only one who'd appreciate it. Happy weekend, Doug - -- "You're walkin' the wire, pain and desire. Looking for love in between." - The Eagles, "Victim of Love" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/WSAlyIakK9Wy8PsRAjmMAJ9mnQtQlGPxAevhICdn69s9JgL2aQCgyvbt EJtZHeZ1gyQu85ATmpBj/1s= =9qK0 -END PGP SIGNATURE-
Re: Sobig.f surprise attack today
On Fri, 22 Aug 2003, Owen DeLong wrote: > Sure, it won't happen in 30 minutes, but, I don't understand why this > wasn't started when F-Secure first noticed the situation. I seriously doubt that most (any?) ISP would be willing to accept the legal liability for altering anything on the computer of a third party that just happened to connect to an IP in a netblock they are responsible for. White worms are an elegant engineering concept, but have little practical value (and huge risk) outside of networks that you control directly. Doug -- "You're walkin' the wire, pain and desire. Looking for love in between." - The Eagles, "Victim of Love"
Re: 69/8...this sucks
On Mon, 10 Mar 2003, E.B. Dreger wrote: > The suggestion is to move ALL root, and as many TLD as possible, > servers into the new space. Nobody has said "move one or two", > which indeed would be ineffective. Ah, sorry, I wasn't aware of the full extent of your crack-smoking-ness. :) You'll never get all of the root server operators to agree on this (or much of anything), so that leaves the root out (even if this were a good idea, which it isn't). Since for sufficiently useful definitions of "all," all of the TLD's are commercial entities, you'll never get them to volunteer to break their own domains, and their customers would riot if they did. Suffice it to say, this idea is never going to happen, although if it takes energy away from the "ldap is the solution to all problems" thread, feel free to keep discussing it. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more.
Re: 69/8...this sucks
On Mon, 10 Mar 2003, E.B. Dreger wrote: > > JSW> Date: 10 Mar 2003 15:23:52 -0500 > JSW> From: Jeff S Wheeler > > > JSW> I repeat my suggestion that a number of DNS root-servers or > JSW> gtld-servers be renumbered into 69/8 space. If the DNS > JSW> "breaks" for these neglected networks, I suspect they will > JSW> quickly get enough clue to fix their ACLs. > JSW> > JSW> Add Eddy's suggestion that the addresses all end in .0 or > JSW> .255 and you have a fine machine for cleaning up a few old, > JSW> irritating problems. > > I suggest a rotation like so: > > Jan-Apr: 69.w.w.0 > Apr-Jul: 69.x.x.255 > Jul-Oct: 70.y.y.0 > Oct-Jan: 70.z.z.255 This wouldn't actually accomplish what you're trying to do. The resolvers that couldn't reach those root and/or TLD servers that are behind the 'broken' networks would simply shift their traffic to the ones that they could reach. The only thing you'd accomplish by this is an increased load on the root/TLD servers that are in their normal locations. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more.
Re: [Re: [Re: M$SQL cleanup incentives]]
On Sat, 22 Feb 2003, E.B. Dreger wrote: > BB> Recent versions of un*x BIND will pick a random port above > BB> 1024 for udp conversations. It can and has picked 1434. > > Standard socket(2) behavior. BIND [hopefully] runs chown(2)ed, > so the source port number must be >= 1024. At startup, named bind(2)'s a UDP port to send queries from, and get the answers back on. In the absence of a query-source option that specifies otherwise, this will be a random ephemeral port, however that's defined on the system. TCP queries follow "standard" behavior, binding a random ephemeral port for each query. Pardon the pedantry, but since this is an often misundertood topic, I thought it might help to lay out the facts. HTH, Doug -- "The last time France wanted more evidence, it rolled right through Paris with a German flag." - David Letterman
Re: DOS?
On Sat, 25 Jan 2003, Christopher J. Wolff wrote: > > Greetings, > > It looks like all hell is breaking loose on some of the nations > backbones. http://www.internethealthreport.com > > The port counters on my AT&T DS3 were reading in the 250 megabit range, > that is a DS3, mind you. > > Any source IP's I can add to the circular file would be appreciated. > Any ranges I find I'll echo back to the list. It's an MS SQL worm that is sending and receiving UDP on 1434. http://www.nextgenss.com/advisories/mssql-udp.txt appears to be relevant. Anyone want to get involved in some sort of real time chat (like IRC) to disuss strategies? We're seeing some pretty big traffic, and related problems in multiple colo's world wide. Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!?
Re: CC-TLD .af
Hendrianto Muljawan wrote: Hello all, does anybody knows the NIC for Afghanistan ? Your request seemed to indicate that you'd been here already, but just in case I thought I'd point out that I've found the page at http://www.iana.org/cctld/cctld-whois.htm to be generally pretty accurate. At least, the entry for .af gives you a few more e-mail addresses to try, and some phone numbers. Also, if you find that the information there is not up to date, [EMAIL PROTECTED] is generally appreciative of your feedback. Hope this helps. -- Doug Barton, Yahoo! DNS Administration and Development
Re: Yahoogroups
On Sat, 21 Dec 2002, blitz wrote: > > Mail to yahoogroups for two days is giving some strange responses. > > Mail is attempting to go to 172.16.3.10 when sent to a yahoogroup. Yahoo! does use RFC 1918 space internally, but we're not using that block. Therefore it's (hopefully) not something gone wacky on our end. Do you have access to a command line somewhere that you can run dig from? If so, please mail me privately and we can try to work out what's going on. Doug Barton Yahoo! DNS Administration
Re: DNS issues various
On Thu, 24 Oct 2002, Simon Waters wrote: > Last time it was discussed I thought that the provisions already > in the DNS RFC's to allow zone transfer for "." to recursive > servers is a neat solution for the root zone. There are pluses and minuses to that approach. The people at .biz and .info are _still_ getting complaints from people sitting behind broken resolvers with bogus copies of the root zone. Doing this in a widespread manner is likely to lead to more problems of this sort for new TLD's, and updates to existing ones. Also, if you consider that of root server queries are for the same say, 10 TLD's, and that those records are cached for 2 days, it would most likely be a net increase in root server traffic to have millions of resolvers slaving the zone. Speaking only for myself, I think the combination of anycast and DNSSEC has the best chance of success; both for the root and gTLD servers. Doug
Re: Who does source address validation? (was Re: what's that smell?)
On Tue, 8 Oct 2002, Iljitsch van Beijnum wrote: > Ok, but how do you generate megabits worth of traffic for which there is > no return traffic? At some level, someone or something must be trying to > do something _really hard_ but keep failing every time. It just doesn't > make sense. I could show you VOLUMES of name server logs for people doing things that could never possibly succeed, over and over and over again. My favorite are the people who try to use my authoritative name servers as resolvers. No one at my company can recall a time that our auth. name servers EVER allowed recursion. My point is simply that we shouldn't underestimate the stupidity of the masses, and anything that can be done to improve things, should be. Of course, the problem in this thread is the varying definitions of "improve." Doug
RE: Thanks! Re: Re: Root DNS Server Issues?
On Fri, 4 Oct 2002, Bodie Francis wrote: > I am sure Doug and others could use this to reduce the typing (the reason > Unix was invented) when doing recursive queries for delegations (it even > identifies lame delegations quite nicely.) Sorry if I wasn't clear. My example was intended to be pedantic, as opposed to actually being useful. dnstracer is an interesting program, but I have a home-grown tool of my own that I use for day to day delegation chain sniffing. The dig in bind 9 also has a new trace option that's fairly useful. Doug
Re: Thanks! Re: Re: Root DNS Server Issues?
On Tue, 1 Oct 2002, John Neiberger wrote: > > Thanks to everyone who helped me out and I hope you don't mind > me making a fool of myself. :-) I (and others that I work > with) learned quite a lot from your responses to this little > incident. If I have to be a little bit foolish to learn > something valuable, then so be it! If you have a copy of "DNS and BIND" laying around the office somewhere, grab it and read the first two or three chapters. They do an excellent job of describing how the distributed domain name system works. This would be good background knowledge for anyone in the business at this level, and it should only take you 30 minutes (or so) to read. The one difference between what older versions of the book describe and current reality is that the root servers, [a-m].root-servers.net, are no longer authoritative for most of the gTLD zones. They have moved to [a-m].gtld-servers.net. For those who would like to see a reader's digest version of how the delegation chain works, try the following: dig @a.root-servers.net. com. ns dig @a.gtld-servers.net. yahoo.com. ns dig @ns1.yahoo.com. www.yahoo.com. ns dig @za.akadns.net. www.yahoo.akadns.net. a That's roughly the path that a resolver would take to figure out how to deal with you typing "www.yahoo.com" into your browser. Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!?
Re: $400 million network upgrade for the Pentagon
Blake Fithen wrote: >>Brad Knowles: >> The Pentagon has windows. It also has an ancient system of air >>pipes aimed at all of the windows... > > > > > Is this sensitive info? Given that I saw this on the history channel the other night, I'd say no. :) -- Doug Barton, Yahoo! DNS Administration and Development You can have it done fast, done cheap, or done right. Pick two. Do YOU Yahoo!?
Re: CA Power
On Thu, 11 Jul 2002, Gary E. Miller wrote: > > Yo Martin! > > If there is plenty of power in CA then howcum there was a "stage 2" alert > yesterday and a "market alert today"? Today's "projected demand" equaled > "available resources" today If demand played out as expected there > would have been big trouble in CA today. I hesitate to respond to this, but the power problems are discussed often enough here that it's almost "on topic..." Last summer, on one of the rolling blackout days, one of our intrepid news stations in San Diego went down to interview one of our independent power plant operators. They were standing next to an idle generating plant, and the interview went something like this: Reporter: So, how many generators do you have at this plant? Operator: 3 R: How many do you have operating today? O: Just one. R: REALLY? But we had rolling blackouts all through San Diego County today, why aren't you operating all 3 generators? O: Because Cal-ISO told me to turn off #2, and not to turn #3 on at all. They went on to talk about all sorts of numbers, that basically added up to just one of those generators could have supplied the difference between supply and demand that day. They never did get a straight answer from Cal-ISO about why they requested that operator to turn his generator(s) off, but the obvious implication was that something was rotten in Denm^WCalifornia. Doug
Re: bulk email
James Cronin wrote: > > Hi, > > I'm working on a bulk (opt in!) email delivery system at the moment, > and over the years I've heard a number of possibly apocryphal > stories about people requiring contracts with large email suppliers > (Hotmail, AOL, Yahoo, MSN etc..) in order to be able to guarantee > delivery and lower the risk of email that's been requested by an > end user being mistakenly blackholed or treated as spam by their > ISP (or webmail provider). http://help.yahoo.com/help/us/mail/spam/spam-17.html -- Doug Barton, Yahoo! DNS Administration and Development If you're never wrong, you're not trying hard enough. Do YOU Yahoo!?
Re: is your host or dhcp server sending dns dynamic updatesforrfc1918?
"Martin J. Levy" wrote: > I wanted to add a flag to bind to "silently ignore" these requests, but > alas this is not a good solution for reverse-dns private space. I have a very simple patch to BIND 8.3.1 to create a category just for these requests so that they can easily be sent to the null channel. Happy to send it on if anyone is interested. Also, since I operate authoritative DNS servers for our *mumble*BIGNUM*mumble* customers, we used to get besieged by these update requests from our eager new customers who named their home (or office, whatever) computers in their shiny new domain name. At one point, the server listed in the MNAME field of the SOA got more update requests than queries! My solution for this was to change the MNAME field to no-dyn-updates.san.yahoo.com, which resolves to the loopback address. (After overcoming tremendous temptation to make it resolve to 207.46.138.20.) W2k's behavior here is truly horrible... it sends 5 requests at startup, then keeps sending requests, apparently forever, till it gets an answer it thinks it likes. Before taking this step, I tested it fairly thoroughly, and got the advice of some windows experts on whether this would break things. It's been in place for about 6 months now, and so far we haven't heard a single complaint. The only problem this ever causes is when registering domains through certain ccTLD registries that require MNAME to be one of the servers listed in the NS set. -- Doug Barton, Yahoo! DNS Administration and Development If you're never wrong, you're not trying hard enough. Do YOU Yahoo!?
