On 9/6/2011 8:40 PM, Mark Andrews wrote:
In message4e66b5b5.30...@chrysler.com, Kevin Darcy writes:
On 9/1/2011 7:57 PM, Mark Andrews wrote:
In message4e5fb1ab.4040...@data.pl, Torinthiel writes:
On 09/01/11 17:56, Tom Schmitt wrote:
=20
I found the cause of my problem (and a solution):
=20
On 9/1/2011 7:57 PM, Mark Andrews wrote:
In message4e5fb1ab.4040...@data.pl, Torinthiel writes:
On 09/01/11 17:56, Tom Schmitt wrote:
=20
I found the cause of my problem (and a solution):
=20
dig +trace actually has another behaviour than doing the trace manually=
step by step with dig.
In message 4e66b5b5.30...@chrysler.com, Kevin Darcy writes:
On 9/1/2011 7:57 PM, Mark Andrews wrote:
In message4e5fb1ab.4040...@data.pl, Torinthiel writes:
On 09/01/11 17:56, Tom Schmitt wrote:
=20
I found the cause of my problem (and a solution):
=20
dig +trace actually has another
In my case, dig is asking for the nameservers of the root-zone and is
getting the answer:
. IN NS root1
. IN NS root2
etc
Next dig is asking for the A-record of root1. And here is the
differrence:
If I do dig root1 dig is asking exactly this, it is asking for the
dig +trace calls getaddrinfo() and that needs to be able to resolve
the hostname (without dots at the end). getaddrinfo() is called
so that we don't have to have a full blown iterative resolver in
dig.
I see. So no way to solve this one in dig itself.
The Internet moved from being a
Hi Tom,
At 23:42 01-09-2011, Tom Schmitt wrote:
But seriously: I don't see in the RFC that it is forbidden to have a
hostname directly in the root-zone (without a internal dot).
From RFC 921:
The names are being changed from simple names, or globally unique
strings, to structured names,
I found the cause of my problem (and a solution):
dig +trace actually has another behaviour than doing the trace manually step by
step with dig.
For a trace, dig is asking for the NS-records, then for the IP-address of the
nameserver found and then go on asking this nameserver. Till the
7 matches
Mail list logo
