> >>
> >>dig @f.root-servers.net hostname.bind chaos txt
> >>
>
> Joe
>
leads to the question that should occur elsewhere, BUT,
why are there all these different ways to ID DNS servers?
granted, the ISC reference implementation was first
out, with the "vers
> Hard data:
see Subject: ORG was broken with serious customer impact,
and for a while. and it took a while to debug. qed
randy
On 17 Oct 2003, at 03:47, Randy Bush wrote:
Incidentally, there is a similar mechanism available for the F root
nameserver, in case people are not aware:
dig @f.root-servers.net hostname.bind chaos txt
For most people this will reveal a nameserver hostname with a "PAO" or
an SFO in it. Peopl
On 17.10 09:47, Randy Bush wrote:
>
> but one has little assurance that the response is from the same
> server as the one from which one had the dns response one is debugging.
That is true. However this only matters if the operator of the server
allows them to be inconsistent *and* routing so vo
> Incidentally, there is a similar mechanism available for the F root
> nameserver, in case people are not aware:
>
>dig @f.root-servers.net hostname.bind chaos txt
>
> For most people this will reveal a nameserver hostname with a "PAO" or
> an SFO in it. People within the catchment of a l
At 03:30 PM 10/16/2003, Rodney Joffe wrote:
Bruce Campbell wrote:
[much snipped]
> Also, did the query that I'm debugging really go to the same host that I
> just got the real IP address from?
I believe I covered that in my initial response to Randy which you
snipped. I said:
"> Dan Senie has s
On 16 Oct 2003, at 11:25, Bruce Campbell wrote:
I know to look for 'version.bind', 'id.server', 'version.server' and a
few
others, but I hadn't considered asking for 'whoareyou.arbitary.domain'.
Why would other people consider it?
Incidentally, there is a similar mechanism available for the F r
Bruce Campbell wrote:
>
> On Thu, 16 Oct 2003, Rodney Joffe wrote:
> > However as the dns was walked, if indeed a server had a problem, in a
> > non-anycast implementation you could tell which server ip address had
> > the problem. But you could not always tell which actual machine had a
> > p
On Thu, 16 Oct 2003, Rodney Joffe wrote:
> Randy Bush wrote:
>
> > and what assurance do you have that the traceroute is to the same
> > server to which the original query failed?
> >
> > difficulty debugging anycast dns was the major reason for sceptisim
> > re anycast auth servers.
>
> However
On Wed, 15 Oct 2003, Rodney Joffe wrote:
> Joe sent a note that identified a possible common thread in the version
> of bind the recursive servers were using. Could you perhaps look at that
> and see if there is any commonality?
I'll see what I can do about that. Unfortunately, the folks complai
> it would appear that given the large scale
> ddos attacks against networks, and dns in particular over the last year,
> an anycast implementation is the *only* way that dns has a chance of
> surviving.
It might help but isn't a cure all.
If they can query it they can DoS it and given the spla
Randy Bush wrote:
> and what assurance do you have that the traceroute is to the same
> server to which the original query failed?
>
> difficulty debugging anycast dns was the major reason for sceptisim
> re anycast auth servers.
You're right, Randy. However, things are never black or white.
> If you or any other folks ever see any oddness with the UltraDNS
> nameservers, it would be helpful if you could provide traceroutes.
and what assurance do you have that the traceroute is to the same
server to which the original query failed?
difficulty debugging anycast dns was the major reas
William,
William Astle wrote:
>
>
> That might explain the complaints some of my customers are getting from
> people unable to send email to them at their .org domains. What I'm seeing
> is this:
>
> Even though my name servers are working correctly and answering up the
> correct information f
On Thu, 16 Oct 2003, Joe Abley wrote:
>
> I think I'm seeing problems performing recursive queries for names
> under ORG against tld[12].ultradns.net at the moment, which is causing
> resolvers without cached data to behave as if domains don't exist.
>
> It's not trivial to tell whether this is j
Hello Joe,
Joe Abley wrote:
>
> I think I'm seeing problems performing recursive queries for names
> under ORG against tld[12].ultradns.net at the moment, which is causing
> resolvers without cached data to behave as if domains don't exist.
>
> It's not trivial to tell whether this is just a lo
On Thu, Oct 16, 2003 at 12:05:25AM -0400, Joe Abley wrote:
>
> I think I'm seeing problems performing recursive queries for names
> under ORG against tld[12].ultradns.net at the moment, which is causing
> resolvers without cached data to behave as if domains don't exist.
>
> It's not trivial t
I think I'm seeing problems performing recursive queries for names
under ORG against tld[12].ultradns.net at the moment, which is causing
resolvers without cached data to behave as if domains don't exist.
It's not trivial to tell whether this is just a local problem, since
all the authoritative
18 matches
Mail list logo
