RE: RFC2468
> 8 years ago today was the beginning of the end. No, it was the end of the beginning. Tony
Re: AT&T refuses to provide PTR records?
Mike Walter wrote: We have a customer that has AT&T and they reassigned the IP space to our name servers to allow us to do reverse DNS for them. We had a similar situation. AT&T states that they will only handle rDNS using domains that they control. They will happily CNAME the IPs appropriately or reassign the IP space, depending on block size and request. The issue we ran into was that we couldn't get them to *unassign* a CNAME for an IP block so that it would fail immediately, and so servers (web,ftp, etc) which requested rDNS for the connection information would time out connections waiting for the non-existent nameservers. We weren't really interested in handling rDNS for the IP given that it wasn't handling mail, web, or have any A records pointing to it. It is the easiest way to get it done, though. Jack Bates
RE: AT&T refuses to provide PTR records?
We have a customer that has AT&T and they reassigned the IP space to our name servers to allow us to do reverse DNS for them. Mike Walter, MCP Systems Administrator 3z.net a PCD Company http://www.3z.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Hubbard Sent: Tuesday, October 17, 2006 4:21 PM To: NANOG list Subject: AT&T refuses to provide PTR records? Anyone familiar with AT&T's policies on PTR records for their customer-assigned address space? We have a customer whose website we host that has their own in-house mail server that they run off of their AT&T internet connection at their office. We handle the DNS for their domain name. AT&T is refusing to set up PTR records for them because they're not handling DNS for the domain name. Is this normal? I haven't dug through the ARIN agreements but I thought it was required to provide reverse DNS on your allocations. Thanks, David
Bellsouth Outage?
Does anyone have additional info or an RFO regarding the Bellsouth Internet Services outage. Apparently it affected all nine states of their region.Please reply offline if you'd like. thanksPablo
AT&T refuses to provide PTR records?
Anyone familiar with AT&T's policies on PTR records for their customer-assigned address space? We have a customer whose website we host that has their own in-house mail server that they run off of their AT&T internet connection at their office. We handle the DNS for their domain name. AT&T is refusing to set up PTR records for them because they're not handling DNS for the domain name. Is this normal? I haven't dug through the ARIN agreements but I thought it was required to provide reverse DNS on your allocations. Thanks, David
Cox.net Contact
Hello, If anyone from cox.net is reading, would you please contact me offlist? Thanks. -Zach
Re: WorldNIC nameserver issues
Chris Owen wrote: On Oct 17, 2006, at 1:36 PM, David Ulevitch wrote: Anyone else seeing these failures? WorldNIC does a lot of authoritative DNS We've got several customer domains in the same boat. I can ping those addresses but they don't seem to be answering queries. I called'em a while ago, they were aware. it should be fixed by now, there would be a fair amount of residual borked traffic.
Re: WorldNIC nameserver issues
On 10/17/2006 2:36 PM, David Ulevitch wrote: > We're seeing a number of issues with WorldNIC nameservers failing > from multiple points on our network this morning and was wondering if > anyone was seeing similar problems. I saw it here with ns89 and ns90 earlier (spent a while tracking down the problem, and their servers were all timing out on queries) but it seems to be working fine now. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: [dns-operations] WorldNIC nameserver issues
David Ulevitch wrote: We're seeing a number of issues with WorldNIC nameservers failing from multiple points on our network this morning and was wondering if anyone was seeing similar problems. We're seeing issues with: ns47.worldnic.com (domain: cpurocket.com) ns48.worldnic.com (domain: cpurocket.com) ns87.worldnic.com (domain insightcollect.com) ns88.worldnic.com (domain insightcollect.com) and many many more... Seen from Europe, Germany, Darmstadt: > check_soa cpurocket.com NS47.WORLDNIC.com has serial number 2006030200 NS48.WORLDNIC.com has serial number 2006030200 > check_soa cpurocket.com NS47.WORLDNIC.com has serial number 2006030200 NS48.WORLDNIC.com has serial number 2006030200 > check_soa insightcollect.com NS87.WORLDNIC.com has serial number 2006092800 NS88.WORLDNIC.com has serial number 2006092800 > check_soa insightcollect.com NS87.WORLDNIC.com has serial number 2006092800 NS88.WORLDNIC.com has serial number 2006092800 No problems here. Kind regards Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Von-Erthal-Strasse 4 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
RE: WorldNIC nameserver issues
> We're seeing a number of issues with WorldNIC nameservers failing > from multiple points on our network this morning and was wondering if > anyone was seeing similar problems. > > We're seeing issues with: > ns47.worldnic.com (domain: cpurocket.com) > ns48.worldnic.com (domain: cpurocket.com) > ns87.worldnic.com (domain insightcollect.com) > ns88.worldnic.com (domain insightcollect.com) > > and many many more... > > Anyone else seeing these failures? WorldNIC does a lot of > authoritative DNS > > -david We're seeing the same thing with various combinations of WorldNIC name servers. Some work fine, others work but are very slow, others are completely nonresponsive. Seeing it from both MCI and TWT. Andrew Cruse
Re: WorldNIC nameserver issues
On Oct 17, 2006, at 1:36 PM, David Ulevitch wrote:Anyone else seeing these failures? WorldNIC does a lot of authoritative DNSWe've got several customer domains in the same boat.I can ping those addresses but they don't seem to be answering queries.Chris PGP.sig Description: This is a digitally signed message part
WorldNIC nameserver issues
We're seeing a number of issues with WorldNIC nameservers failing from multiple points on our network this morning and was wondering if anyone was seeing similar problems. We're seeing issues with: ns47.worldnic.com (domain: cpurocket.com) ns48.worldnic.com (domain: cpurocket.com) ns87.worldnic.com (domain insightcollect.com) ns88.worldnic.com (domain insightcollect.com) and many many more... Anyone else seeing these failures? WorldNIC does a lot of authoritative DNS -david
Re: AS 701 problems in Chicago ?
On Tuesday 17 Oct 2006 03:32, you wrote: > 205.150.100.214 Sorry - my mistake Saw the 205.150 prefix and confused in with 205.152, which are totally different of course. bellsouth.net have sorted their issue (from our perspective).
Re: AS 701 problems in Chicago ?
At 03:39 AM 10/17/2006, Simon Waters wrote: On Tuesday 17 Oct 2006 03:32, Mike Tancsa wrote: > Anyone know whats up ? I have seen some strange routing depending on > the payload's protocol to a site in one of their colos in Toronto. Don't know if it is related, but we can't route email to bellsouth.net -- no Hi, Thanks for replying, it doesnt seem to be related based on the traceroute you provided. I am still seeing the issue this morning, but its not so wide spread across protocols. I worked around the issue by dumping out my traffic to them via Teleglobe instead of MTSAllstream. Teleglobe seems to talk to them on a different router in Chicago which doesnt seem to be showing the behaviour as much as the other router or at least its not on the source IP addresses I am using. However, its stil blocking IPSEC packets I got an email from the datacenter early this AM saying the problem was fixed according to UUnet, but it still there when I just tried now. Is this the result of some protocol prioritizing config gone bad ? Or busted software ? e.g as of this morning, icmp,tcp, and udp packets make it to the other side but not IPSEC traceroute -s 67.43.129.246 -Pudp 209.167.35 traceroute to 209.167.35.xx (209.167.35.xx) from 67.43.129.246, 64 hops max, 40 byte packets 1 216.191.68.65 (216.191.68.65) 0.877 ms 0.708 ms 0.786 ms 2 65.195.241.149 (65.195.241.149) 12.225 ms 12.262 ms 12.239 ms 3 0.so-1-0-0.XL1.CHI1.ALTER.NET (152.63.70.78) 12.524 ms 12.424 ms 12.443 ms 4 0.so-0-0-0.TL1.CHI2.ALTER.NET (152.63.68.82) 12.870 ms 12.832 ms 12.940 ms 5 0.so-3-0-0.TL1.TOR2.ALTER.NET (152.63.2.85) 28.846 ms 28.633 ms 28.739 ms 6 0.so-1-0-0.XL1.TOR2.ALTER.NET (152.63.3.82) 28.886 ms 74.966 ms 28.789 ms 7 POS6-1.GW4.TOR2.ALTER.NET (152.63.131.129) 28.888 ms 28.691 ms 28.605 ms 8 enoo3-gw.customer.alter.net (205.150.100.214) 34.739 ms 34.998 ms 34.395 ms traceroute -s 67.43.129.246 -Pesp 209.167.35.xx traceroute to 209.167.35.xx (209.167.35.xx) from 67.43.129.246, 64 hops max, 36 byte packets 1 216.191.68.65 (216.191.68.65) 0.918 ms 0.724 ms 0.712 ms 2 65.195.241.149 (65.195.241.149) 12.244 ms 12.311 ms 12.297 ms 3 0.so-1-0-0.XL1.CHI1.ALTER.NET (152.63.70.78) 12.361 ms 12.456 ms 12.404 ms 4 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 12.792 ms 12.784 ms 12.751 ms 5 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 13.356 ms 13.405 ms 13.489 ms 6 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 13.208 ms 13.113 ms 13.131 ms 7 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 13.820 ms 13.833 ms 13.903 ms 8 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 13.666 ms 13.567 ms 13.733 ms 9 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 14.308 ms 14.316 ms 14.345 ms 10 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 14.018 ms 14.113 ms 14.073 ms 11 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 14.807 ms 14.824 ms 14.943 ms 12 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 14.558 ms 14.611 ms 14.595 ms 13 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 15.327 ms 15.335 ms 15.174 ms 14 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 15.031 ms 14.948 ms 15.148 ms 15 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 15.680 ms 15.678 ms 15.688 ms 16 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 15.510 ms 15.498 ms 15.534 ms 17 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 16.189 ms 16.239 ms 16.167 ms 18 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 15.964 ms 15.855 ms 15.924 ms 19 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 16.688 ms 16.629 ms 16.753 ms 20 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 16.385 ms 16.464 ms 16.473 ms 21 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 17.099 ms 17.034 ms 17.134 ms 22 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 77.096 ms 16.821 ms 16.875 ms 23 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 17.488 ms 17.474 ms 17.474 ms 24 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 17.310 ms 17.348 ms 17.323 ms 25 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 18.018 ms 18.137 ms 17.953 ms 26 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 17.838 ms 17.740 ms 17.820 ms 27 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 18.595 ms 18.466 ms 18.484 ms 28 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 18.220 ms 18.256 ms 18.349 ms 29 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 48.198 ms 18.987 ms 18.877 ms 30 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 18.669 ms 18.709 ms 18.769 ms 31 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 19.361 ms 19.565 ms 19.442 ms 32 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 19.121 ms 19.158 ms 19.114 ms 33 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 19.780 ms 20.010 ms 19.907 ms 34 0.so-0-0-0.TL1.CHI4.ALTER.NET (152.63.13.26) 19.610 ms 19.614 ms 19.587 ms 35 0.so-7-0-0.XL1.CHI6.ALTER.NET (152.63.65.161) 20.329 ms 20.239 ms 20.269 ms 36 0.so-0-0-0.
Re: AS 701 problems in Chicago ?
On Tuesday 17 Oct 2006 03:32, Mike Tancsa wrote: > Anyone know whats up ? I have seen some strange routing depending on > the payload's protocol to a site in one of their colos in Toronto. Don't know if it is related, but we can't route email to bellsouth.net -- no route to host. When I checked it rattles around inside their network (assuming traceroute is trustworthy). Their customer support (first number I found) report they have a ticket already open. They know they have a problem, but didn't supply any details, I didn't ask. I just wanted to know it wasn't specific to our own address space, and they knew they had a problem, it isn't, they do. Snip first few hops. 9 dhr4-pos-8-0.Weehawkennj2.savvis.net (204.70.1.6) 87.029 ms 78.880 ms 93.625 ms 10 0.ge-5-1-0.XL4.NYC4.ALTER.NET (152.63.3.121) 80.281 ms 76.763 ms 85.844 ms 11 0.so-6-0-0.XL2.ATL5.ALTER.NET (152.63.10.105) 111.373 ms 110.133 ms 106.262 ms 12 0.so-7-0-0.GW13.ATL5.ALTER.NET (152.63.84.109) 100.764 ms 114.852 ms 107.897 ms 13 bellsouth-atl5-gw.customer.alter.net (157.130.71.170) 103.411 ms 102.371 ms 95.479 ms 14 axr00asm-1-0-0.bellsouth.net (65.83.236.3) 95.399 ms 99.486 ms 99.574 ms 15 ixc00asm-4-0.bellsouth.net (65.83.237.1) 96.381 ms 96.492 ms 101.427 ms 16 acs01asm.asm.bellsouth.net (205.152.37.66) 109.901 ms 118.113 ms 111.783 ms 17 axr01asm-1-3-1.bellsouth.net (65.83.237.6) 96.847 ms 102.503 ms 96.839 ms 18 65.83.238.40 (65.83.238.40) 96.554 ms 96.587 ms 96.480 ms 19 65.83.238.37 (65.83.238.37) 110.986 ms 110.987 ms 118.938 ms 20 65.83.239.29 (65.83.239.29) 110.261 ms 115.079 ms 110.075 ms 21 65.83.239.102 (65.83.239.102) 110.098 ms 110.116 ms 110.158 ms 22 205.152.45.65 (205.152.45.65) 110.158 ms 110.263 ms 110.142 ms 23 205.152.161.63 (205.152.161.63) 109.775 ms 110.116 ms 115.274 ms 24 205.152.161.65 (205.152.161.65) 110.571 ms 110.576 ms 110.512 ms 25 205.152.161.48 (205.152.161.48) 118.745 ms 116.560 ms 112.485 ms 26 * * * 27 205.152.156.25 (205.152.156.25) 128.332 ms 128.274 ms 133.991 ms 28 205.152.161.49 (205.152.161.49) 132.822 ms 141.624 ms 143.536 ms 29 205.152.161.64 (205.152.161.64) 142.537 ms 131.862 ms 132.765 ms 30 205.152.161.62 (205.152.161.62) 132.566 ms 131.734 ms 134.176 ms
