Comparing DNS servers?

I have no idea if this is the best group to post this question, apologies if
it's not.

Are there any website which test alternative DNS servers resolving accuracy?
It would be useful to give an indication of how a change of name servers
propagates through the network.

Many thanks.

"Fredxx" <> wrote in message
news:h6f630$spp$...
>I have no idea if this is the best group to post this question, apologies
>if it's not.
>
> Are there any website which test alternative DNS servers resolving
> accuracy? It would be useful to give an indication of how a change of name
> servers propagates through the network.
>
> Many thanks.

Resolving accuracy? They either resolve what's in their database, or if it
doesn't exist, they provide a NULL response (they don't have the answer). So
I'm not sure what you mean in this respect.

As far as a change of nameservers, do you mean for your public record or for
AD? If public records, that take a little time to propagate due to the TTL
time on the records. If AD, if you add a DNS server, assuming the zone is AD
integrated, it depends on the network's topology and replication schedule.


--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum to benefit from collaboration
among responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.

"Ace Fekay [MCT]" <> wrote in message
news:...
> "Fredxx" <> wrote in message
> news:h6f630$spp$...
>>I have no idea if this is the best group to post this question, apologies
>>if it's not.
>>
>> Are there any website which test alternative DNS servers resolving
>> accuracy? It would be useful to give an indication of how a change of
>> name servers propagates through the network.
>>
>> Many thanks.
>
> Resolving accuracy? They either resolve what's in their database, or if it
> doesn't exist, they provide a NULL response (they don't have the answer).
> So I'm not sure what you mean in this respect.
>
> As far as a change of nameservers, do you mean for your public record or
> for AD? If public records, that take a little time to propagate due to the
> TTL time on the records. If AD, if you add a DNS server, assuming the zone
> is AD integrated, it depends on the network's topology and replication
> schedule.
>
>

You hit the nail on the head when you said what's in their database. Are
there any websites which compare the results?

I thought most TTLs are in the order of a couple of hours, but it seems to
take far longer for any changes to propagate across the internet, making
email unreliable for our customers for a couple of days.

Many thanks.

If a DNS server doesn't have a Cached response to a record it will seek
an answer via whatever means it has been told to. Typically that either
means via a Forwarder or via Root Hints. The latter will eventually lead
back to the DNS server that can provide an up to date answer where a
Forwarder may still provide a cached response.

The TTL itself is entirely arbitrary, it can be set to almost anything.
Most tend to be in the 24 to 48 hour range, but it can go either way
(shorter or longer).

It's one of those things you must account for if you're making changes
to records. In the case of an MX that can include inserting a new MX
record prior to the change (while the new system is offline), or
reducing the TTL.

Chris

Fredxx wrote:
> "Ace Fekay [MCT]" <> wrote in message
> news:...
>> "Fredxx" <> wrote in message
>> news:h6f630$spp$...
>>> I have no idea if this is the best group to post this question, apologies
>>> if it's not.
>>>
>>> Are there any website which test alternative DNS servers resolving
>>> accuracy? It would be useful to give an indication of how a change of
>>> name servers propagates through the network.
>>>
>>> Many thanks.
>> Resolving accuracy? They either resolve what's in their database, or if it
>> doesn't exist, they provide a NULL response (they don't have the answer).
>> So I'm not sure what you mean in this respect.
>>
>> As far as a change of nameservers, do you mean for your public record or
>> for AD? If public records, that take a little time to propagate due to the
>> TTL time on the records. If AD, if you add a DNS server, assuming the zone
>> is AD integrated, it depends on the network's topology and replication
>> schedule.
>>
>>
>
> You hit the nail on the head when you said what's in their database. Are
> there any websites which compare the results?
>
> I thought most TTLs are in the order of a couple of hours, but it seems to
> take far longer for any changes to propagate across the internet, making
> email unreliable for our customers for a couple of days.
>
> Many thanks.
>
>

Not sure what you mean about "inserting a new MX" record?

Both new and old mail servers were operating, the problem was the old server
one knew the old IP address was wrong and returned a failure notice.

As you say 48 hours later, all's well. Bit not sure how to ensure future
moves won't have the same problem.

How would I change the TTL? DNS servers aren't under my control?
Many thanks for your reply.


"Chris Dent" <> wrote in message
news:...
>
> If a DNS server doesn't have a Cached response to a record it will seek an
> answer via whatever means it has been told to. Typically that either means
> via a Forwarder or via Root Hints. The latter will eventually lead back to
> the DNS server that can provide an up to date answer where a Forwarder may
> still provide a cached response.
>
> The TTL itself is entirely arbitrary, it can be set to almost anything.
> Most tend to be in the 24 to 48 hour range, but it can go either way
> (shorter or longer).
>
> It's one of those things you must account for if you're making changes to
> records. In the case of an MX that can include inserting a new MX record
> prior to the change (while the new system is offline), or reducing the
> TTL.
>
> Chris
>
> Fredxx wrote:
>> "Ace Fekay [MCT]" <> wrote in message
>> news:...
>>> "Fredxx" <> wrote in message
>>> news:h6f630$spp$...
>>>> I have no idea if this is the best group to post this question,
>>>> apologies if it's not.
>>>>
>>>> Are there any website which test alternative DNS servers resolving
>>>> accuracy? It would be useful to give an indication of how a change of
>>>> name servers propagates through the network.
>>>>
>>>> Many thanks.
>>> Resolving accuracy? They either resolve what's in their database, or if
>>> it doesn't exist, they provide a NULL response (they don't have the
>>> answer). So I'm not sure what you mean in this respect.
>>>
>>> As far as a change of nameservers, do you mean for your public record or
>>> for AD? If public records, that take a little time to propagate due to
>>> the TTL time on the records. If AD, if you add a DNS server, assuming
>>> the zone is AD integrated, it depends on the network's topology and
>>> replication schedule.
>>>
>>>
>>
>> You hit the nail on the head when you said what's in their database. Are
>> there any websites which compare the results?
>>
>> I thought most TTLs are in the order of a couple of hours, but it seems
>> to take far longer for any changes to propagate across the internet,
>> making email unreliable for our customers for a couple of days.
>>
>> Many thanks.
>>

Fredxx wrote:

> Not sure what you mean about "inserting a new MX" record?

It is a useful work-around if you can't change the TTL for the existing
record.

Say you had an MX record like this before moving over:

domain.com. IN MX 10 mail.domain.com.

That's all fine until you want to change things. However, you could make
the MX record into this prior to the change:

domain.com. IN MX 10 mail.domain.com. <-- The existing mail server
domain.com. IN MX 20 newmail.domain.com. <-- The new mail server

Now if mail.domain.com is offline systems sending mail will attempt to
deliver mail to newmail.domain.com.

If newmail.domain.com is offline as well then delivery will be deferred
in the usual manner.

If we fast-forward to the change-over, mail.domain.com won't be online
anymore, but that's okay because the secondary MX, newmail, will be and
messages will be delivered there.

The old, and now redundant, MX record would be removed post-change.

If you opt for this kind of change over it must be made far enough in
advance that anyone who might have a cached / remembered version of your
MX will have time to figure it out. So typically you'd make this kind of
change between 2 days to a week in advance of the change-over.

> How would I change the TTL? DNS servers aren't under my control?

For that you would need to be able to have access to the DNS service
(some ISPs permit TTL changes via a web-page interface to DNS). If you
don't have access at all you may be able to ask for it to be changed on
your behalf, otherwise the method above works well.

Chris

Chris Dent wrote:
> Fredxx wrote:
>
>> Not sure what you mean about "inserting a new MX" record?
>
> It is a useful work-around if you can't change the TTL for the
> existing record.
>
> Say you had an MX record like this before moving over:
>
> domain.com. IN MX 10 mail.domain.com.
>
> That's all fine until you want to change things. However, you could
> make the MX record into this prior to the change:
>
> domain.com. IN MX 10 mail.domain.com. <-- The existing mail
> server domain.com. IN MX 20 newmail.domain.com. <-- The new mail
> server
> Now if mail.domain.com is offline systems sending mail will attempt to
> deliver mail to newmail.domain.com.
>
> If newmail.domain.com is offline as well then delivery will be
> deferred in the usual manner.
>
> If we fast-forward to the change-over, mail.domain.com won't be online
> anymore, but that's okay because the secondary MX, newmail, will be
> and messages will be delivered there.
>
> The old, and now redundant, MX record would be removed post-change.
>
> If you opt for this kind of change over it must be made far enough in
> advance that anyone who might have a cached / remembered version of
> your MX will have time to figure it out. So typically you'd make this
> kind of change between 2 days to a week in advance of the change-over.
>
>> How would I change the TTL? DNS servers aren't under my control?
>
> For that you would need to be able to have access to the DNS service
> (some ISPs permit TTL changes via a web-page interface to DNS). If you
> don't have access at all you may be able to ask for it to be changed
> on your behalf, otherwise the method above works well.
>
> Chris

Many thanks for that, I'm not sure if I have that level of control, but will
be much wiser next time!

"Fredxx" <> wrote in message
news:h6h0od$5vu$...
> Chris Dent wrote:
>> Fredxx wrote:
>>
>>> Not sure what you mean about "inserting a new MX" record?
>>
>> It is a useful work-around if you can't change the TTL for the
>> existing record.
>>
>> Say you had an MX record like this before moving over:
>>
>> domain.com. IN MX 10 mail.domain.com.
>>
>> That's all fine until you want to change things. However, you could
>> make the MX record into this prior to the change:
>>
>> domain.com. IN MX 10 mail.domain.com. <-- The existing mail
>> server domain.com. IN MX 20 newmail.domain.com. <-- The new mail
>> server
>> Now if mail.domain.com is offline systems sending mail will attempt to
>> deliver mail to newmail.domain.com.
>>
>> If newmail.domain.com is offline as well then delivery will be
>> deferred in the usual manner.
>>
>> If we fast-forward to the change-over, mail.domain.com won't be online
>> anymore, but that's okay because the secondary MX, newmail, will be
>> and messages will be delivered there.
>>
>> The old, and now redundant, MX record would be removed post-change.
>>
>> If you opt for this kind of change over it must be made far enough in
>> advance that anyone who might have a cached / remembered version of
>> your MX will have time to figure it out. So typically you'd make this
>> kind of change between 2 days to a week in advance of the change-over.
>>
>>> How would I change the TTL? DNS servers aren't under my control?
>>
>> For that you would need to be able to have access to the DNS service
>> (some ISPs permit TTL changes via a web-page interface to DNS). If you
>> don't have access at all you may be able to ask for it to be changed
>> on your behalf, otherwise the method above works well.
>>
>> Chris
>
> Many thanks for that, I'm not sure if I have that level of control, but
> will be much wiser next time!
>
>


As stated, this is normally something you have to plan. I make my changes on
a Friday afternoon, for the most part, some of it's ready by the next day,
but it will all have propogated by Monday morning's start of business.

Ace