Nice to get news third string...
//
Last week, ICANN setup a new IP address for one of the thirteen root
name servers that oversee DNS queries across the net, and it plans on
retiring the old address as soon as the late spring.
On Nov 6, 2007, at 3:06 PM, J. Oquendo wrote:
Nice to get news third string...
//
Last week, ICANN setup a new IP address for one of the thirteen root
name servers that oversee DNS queries across the net, and it plans on
retiring the old address as soon as the late spring.
On Tue, 6 Nov 2007, J. Oquendo wrote:
http://www.theregister.co.uk/2007/11/06/icann_rolls_out_new_root_name_server_address/
Here is what I posted the last time.
To: 'nanog@merit.edu' nanog@merit.edu
Subject: Don't Panic II (Re: updated root hints file)
From: Sean Donelan [EMAIL
On Nov 6, 2007, at 3:24 PM, Patrick W. Gilmore wrote:
On Nov 6, 2007, at 3:06 PM, J. Oquendo wrote:
Nice to get news third string...
//
Last week, ICANN setup a new IP address for one of the thirteen root
name servers that oversee DNS queries across the net, and it plans
on
retiring the
On Thu, 09 Aug 2007 22:58:40 -, Paul Vixie said:
How does the (eventual) deployment of DNSSEC change these numbers?
DNSSEC cannot be signalled except in EDNS.
Right. Elsewhere in this thread, somebody discussed ugly patches to keep
the packet size under 512. I dread to think how many
On Thu, 9 Aug 2007 15:53:12 -0700 (PDT)
Doug Barton [EMAIL PROTECTED] wrote:
How many bytes of shell code can you stuff into a 4096 byte EDNS0 UDP
packet? :)
Probably a lot. People used to have 4-line signatures
with the PGP encryption or DECSS. I have a 152-byte C
program that calculates
On Aug 9, 2007, at 2:05 PM, Paul Vixie wrote:
Your comments have helped.
i think you're advising folks to monitor their authority servers to
find out how many truncated responses are going out and how many
TCP sessions result from these truncations and how many of these
TCP sessions are
Your comments have helped.
groovy.
When TCP is designed to readily fail, reliance upon TCP seems questionable.
i caution against being overly cautious about DNS TCP if you're using RFC 1035
section 4.2.2 as your basis for special caution. DNS TCP only competes
directly against other DNS
On Aug 10, 2007, at 4:41 PM, Paul Vixie wrote:
On the other hand, potentially larger messages may offer the
necessary
motivation for adding ACLs on recursive DNS, and deploying BCP 38.
i surely do hope so. we need those ACLs and we need that
deployment, and if
message size and TCP
On 8/9/2007 at 10:07 PM, Mark Andrews [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you write:
I suspect that the origin of the myth that DNS/TCP is more
dangerous than DNS/UDP is that the first root expliot of
named was over TCP not UDP. There were later exploits
On Fri, 10 Aug 2007 16:11:04 -0700
Douglas Otis [EMAIL PROTECTED] wrote:
TCP offers a means to escape UDP related issues. On the other hand,
blocking TCP may offer the necessary motivation for having these UDP
issues fixed. After all, only UDP should be required. When TCP is
On Aug 8, 2007, at 5:35 PM, Paul Vixie wrote:
... but a TCP connection will consume a
significant amount of a name server's resources.
...wrong.
Wanting to understand this comment, ...
the resources given a nameserver to TCP connections are tightly
controlled, as described in RFC
the resources given a nameserver to TCP connections are tightly
controlled, as described in RFC 1035 4.2.2. so while TCP/53 can become
unreliable during high load, the problems will be felt by initiators not
targets.
The relevant entry in Section 1035 4.2.2 recommends that the server
On Thu, 09 Aug 2007 21:05:26 -, Paul Vixie said:
i think you're advising folks to monitor their authority servers to find out
how many truncated responses are going out and how many TCP sessions result
from these truncations and how many of these TCP sessions are killed by the
RFC1035
[EMAIL PROTECTED] writes:
... advising folks to monitor their authority servers to find out how
many truncated responses are going out and how many TCP sessions result
from these truncations and how many of these TCP sessions are killed by
the RFC1035 4.2.2 connection management logic,
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
I suspect that the origin of the myth that DNS/TCP is more
dangerous than DNS/UDP is that the first root expliot of
named was over TCP not UDP. There were later exploits that
were UDP only which totally busted the myth but it continues
to live.
In article [EMAIL PROTECTED] you write:
I suspect that the origin of the myth that DNS/TCP is more
dangerous than DNS/UDP is that the first root expliot of
named was over TCP not UDP. There were later exploits that
were UDP only which totally busted the myth but it
a lot less work to do.
What are the industry best practices for keeping DNS servers secure?
CERT publishes a document on securing DNS:
http://www.cert.org/archive/pdf/dns.pdf
NIST publishes a document on securing DNS:
http://csrc.nist.gov/fasp/FASPDocs/network-security/NISTSecuringDNS.htm
CMYRU
i normally agree with doug
[EMAIL PROTECTED] (Douglas Otis) writes:
Ensuring an authoritative domain name server responds via UDP is a
critical security requirement. TCP will not create the same risk of a
resolver being poisoned, but a TCP connection will consume a significant
amount of
On Aug 8, 2007, at 12:11 PM, Paul Vixie wrote:
[EMAIL PROTECTED] (Douglas Otis) writes:
Ensuring an authoritative domain name server responds via UDP is a
critical security requirement. TCP will not create the same risk
of a resolver being poisoned, but a TCP connection will consume a
... but a TCP connection will consume a
significant amount of a name server's resources.
...wrong.
Wanting to understand this comment, ...
the resources given a nameserver to TCP connections are tightly controlled,
as described in RFC 1035 4.2.2. so while TCP/53 can become unreliable
On Aug 8, 2007, at 6:20 PM, william(at)elan.net [EMAIL PROTECTED]
wrote:
On Tue, 7 Aug 2007, Donald Stahl wrote:
All things being equal (which they're usually not) you could use
the ACK
response time of the TCP handshake if they've got TCP DNS resolution
available. Though again most
All things being equal (which they're usually not) you could use the ACK
response time of the TCP handshake if they've got TCP DNS resolution
available. Though again most don't for security reasons...
Then most are incredibly stupid.
Several anti DoS utilities force unknown hosts to initiate
];
[EMAIL PROTECTED] [EMAIL PROTECTED]
Sent: Tue Aug 07 12:14:11 2007
Subject: RE: large organization nameservers sending icmp packets to dns servers.
All things being equal (which they're usually not) you could use the ACK
response time of the TCP handshake if they've got TCP DNS resolution
From: Joe Abley [EMAIL PROTECTED]
Date: Tue, 7 Aug 2007 15:19:30 -0400
Sender: [EMAIL PROTECTED]
On 7-Aug-2007, at 14:38, Patrick W. Gilmore wrote:
On Aug 7, 2007, at 2:14 PM, Donald Stahl wrote:
All things being equal (which they're usually not) you could use
the ACK
On Aug 7, 2007, at 4:33 PM, Donald Stahl wrote:
[...]
If you don't like the rules- then change the damned protocol. Stop
just doing whatever you want and then complaining when other people
disagree with you.
I think this last part is the key.
Remember the old adage: My network, My
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
On Mon, 06 Aug 2007 11:53:15 EDT, Drew Weaver said:
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?
Sounds like one of the global-scale load balancers - when you do a (presumably)
recursive DNS lookup of one
On Monday 06 August 2007 16:53, 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?
Some of the DNS load balancing schemes do this, I assume to work out how far
away your server is so
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
On Mon, 06 Aug 2007 11:57:08 -0400
[EMAIL PROTECTED] wrote:
On Mon, 06 Aug 2007 11:53:15 EDT, Drew Weaver said:
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?
Sounds like one of the global-scale load
:15 EDT, Drew Weaver said:
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?
Sounds like one of the global-scale load balancers - when you do a
(presumably)
recursive DNS lookup of one of their hosts
On Aug 6, 2007, at 9:13 AM, Leigh Porter wrote:
But why would they care where the nameserver is? Point 2 would seem to
be a little stupid a thing to assume. Also, what happens if, at that
moment, the ICMP packet is stuck in a queue for a few ms making the
shortest route longer.
While
On Mon, 06 Aug 2007 12:13:03 EDT, Steven M. Bellovin said:
1) ICMP is handled at the same rate as TCP/UDP packets in all the
routers involved (so there's no danger of declaring a path slow
when it really isn't, just becase a router slow-pathed ICMP).
This is aimed at hosts, not routers,
Why would they ping rather than just sending the query to all of the
NS and see which one answers first? It's an IP round trip either way.
If you have sites in San Fran, London, and Tokyo, and you launch a ping from
all 3 and see which one gets there first, you'll *know* the RTT from each
On Mon, 06 Aug 2007 16:11:36 EDT, Matthew Crocker said:
But you could, it isn't hard to dump a BGP view into a box from a
border router and use that map to determine the proper DNS records to
return.
It's harder than it looks, given the number of people who pop up on this list
and ask
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
On Aug 6, 2007, at 4:43 PM, [EMAIL PROTECTED] wrote:
On Mon, 06 Aug 2007 16:11:36 EDT, Matthew Crocker said:
But you could, it isn't hard to dump a BGP view into a box from a
border router and use that map to determine the proper DNS records to
return.
It's harder than it looks, given the
I've heard rumour that the problem is not limited to NS59 and NS60 at
WORLDNIC.com, and that use of the the truncate bit is involved in some
cases, forcing queries to use TCP.
Original Message
Subject: Re: Root DNS Servers 2
From: Patrick W. Gilmore [EMAIL PROTECTED]
Date
On Fri, Apr 22, 2005 at 11:16:05AM -0400, Joseph Nuara wrote:
Does anyone know what is currently happening with the root DNS servers?
I'm currently unable to do A and MX lookups on some domains while my
service providers DNS server appears to be ok ...
well, not speaking
On Apr 22, 2005, at 11:47 AM, Christopher L. Morrow wrote:
The problem appears to be with
ipc.com nameserver = NS60.WORLDNIC.com.
ipc.com nameserver = NS59.WORLDNIC.com.
Anyone know what's happening?
note, I'm not a dns admin nor a network engineer, BUT these aren't
root
servers... Perhaps your
On Fri, 22 Apr 2005, Joseph Nuara wrote:
The problem appears to be with
ipc.com nameserver = NS60.WORLDNIC.com.
ipc.com nameserver = NS59.WORLDNIC.com.
Anyone know what's happening?
note, I'm not a dns admin nor a network engineer, BUT these aren't root
servers... Perhaps your host(s)
Does anyone know what is currently happening with the root DNS servers?
I'm currently unable to do A and MX lookups on some domains while my
service providers DNS server appears to be ok ...
The problem appears to be with
ipc.com nameserver = NS60.WORLDNIC.com.
ipc.com nameserver = NS59.WORLDNIC.com.
Anyone know what's happening?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Graeme Clark
Sent: Friday, April 22, 2005 5:52 PM
To: nanog@merit.edu
Subject: RE: Root DNS servers
On Fri, Apr 22, 2005 at 11:16:05AM -0400, Joseph Nuara wrote:
Does anyone know what
]
Subject: Re: lists of DNS servers by region.
Tatsuya Kawasaki wrote:
Many web sites which are mulihome/mult co-located seem to act
differnetly depend on which DNS severs that we use.
Questions:
1. Does anyone have lists of DNS servers by region to may optimize the
path?-- of course
Many DNS load balancing solutions will return the address of the web
server closest to the _query source_. This means these systems work best
when your recursive DNS servers are topologically closest to your users.
Correct me if I am wrong.. But..
I don't think multiple 'A' record load
On Thu, 12 Dec 2002 14:42:08 EST, Haesu said:
Many DNS load balancing solutions will return the address of the web
server closest to the _query source_. This means these systems work best
when your recursive DNS servers are topologically closest to your users.
Correct me if I am wrong
of DNS servers by region to may optimize the
path?-- of course it may depend on the network topology ...Assume that
If ISP is fully messed with others.. ie Teir I provider for exmaple.
2. what is the typical of method they(web hosts) used to decide which one
to give?
Tatsuya
and even combine it with latency if
necessary, in which it will then update your named.conf's view function
section. (Unless you have named.conf split over using include directives
for 'views')
For your secondary nearby DNS servers running BIND9, you should not
slave the zones under view functions b/c
have a look at http://www.nrg4u.com at the bottom of the page BGPDNS.
P.
Many web sites which are mulihome/mult co-located seem to act differnetly
depend on which DNS severs that we use.
Questions:
1. Does anyone have lists of DNS servers by region to may optimize the
path?-- of course it may depend on the network topology ...Assume that
If ISP is fully messed
Tatsuya Kawasaki wrote:
Many web sites which are mulihome/mult co-located seem to act
differnetly depend on which DNS severs that we use.
Questions:
1. Does anyone have lists of DNS servers by region to may optimize the
path?-- of course it may depend on the network topology ...Assume
i am a bit confused here. seems to be that the major differences
between smb's scheme, for which you personally attacked me, and
yours are
o yours has centralized control, you, instead of isp control.
this is known not to have good layer nine properties, see
marinara del roi.
o we
55 matches
Mail list logo
