[NCLUG] Carputer / Megasquirt

[Rob Elsner]

Neil,

Thanks for the detailed information.  I've passed it along to
On Oct 14, 2010 7:36 AM, "Neil Neely" <neil at neely.cx> wrote:
> I've prodded a couple public open DNS resolvers (qwest and google) and
> neither of them can resolve it either. My first assumption was that they
> were missing their glue record (
> http://faq.domainmonster.com/dns/glue_record/) but that turns out not to
be
> the problem.
>
> It looks like they have removed their own A records that defined what
> ns1.msefi.com resolves to.
> If you ask the root for the glue records for ns1.msefi.com and
> ns2.msefi.comthis is what they will give you:
>
> (output trimmed a little)
> $ dig -t NS msefi.com @a.gtld-servers.net
>
> ;; QUESTION SECTION:
> ;msefi.com. IN NS
>
> ;; AUTHORITY SECTION:
> msefi.com. 172800 IN NS ns1.msefi.com.
> msefi.com. 172800 IN NS ns2.msefi.com.
>
> ;; ADDITIONAL SECTION:
> ns1.msefi.com. 172800 IN A 64.50.169.76
> ns2.msefi.com. 172800 IN A 64.50.169.77
>
>
> So that tells a resolving name server that to get the real answers we need
> to talk to either 64.50.169.76 or 64.50.169.77 - so let's go talk to them
> directly:
>
> $ dig -t any ns1.msefi.com @64.50.169.76 +short
> (no value returned)
>
> Let's see if they return anything for that domain:
> $ dig -t SOA msefi.com @64.50.169.76
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45851
> ;; flags: qr *aa* rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;msefi.com. IN SOA
>
> ;; ANSWER SECTION:
> msefi.com. 43200 IN SOA ns1.msefi.com. forumadmin.msefi.com. 2010032100
> 14400 7200 3600000 86400
>
>
> Yes they do... I bolded the AA to show that they are returning the
> authority bit so they think they are authoritative for it, but they are
> telling the world that there is no value for ns1.msefi.com (nor for
> ns2.msefi.com either).
>
> I've never seen this particular combination before, but it is definitely
> wrong.
>
> As for why some places can resolve it and some can't - my assumption
lacking
> better data is DNS caching. DNS records often cache for a long time, and
it
> is generally thought of as a best practice to set the TTL on an NS record
> very long so it will cache as long as possible. Though it is also possible
> that comcasts DNS resolvers are just behaving differently (preserving the
> glue and not trusting the authoritative answer).
>
> FRII just uses BIND, so is pretty vanilla as far as that part of the
> configuration goes.
>
> Neil Neely
> (who runs FRII's DNS servers)
>
>
> On Wed, Oct 13, 2010 at 10:14 PM, Rob Elsner <thatsnotright at gmail.com
>wrote:
>
>> Bob,
>>
>> Thanks for checking. I have an email out to them to see if we can get
this
>> resolved, it would probably be better for their site!
>>
>> I'm still perplexed by the ability of some to resolve and some not to,
but
>> I
>> am not a dns expert. I have a friend on comcast in Denver and it worked
>> fine for him.
>>
>> Thanks again,
>> Rob
>> _______________________________________________
>> NCLUG mailing list NCLUG at lists.nclug.org
>>
>> To unsubscribe, subscribe, or modify
>> your settings, go to:
>> http://lists.nclug.org/mailman/listinfo/nclug
>>
>
>
>
> --
> Neil Neely
> http://neil-neely.blogspot.com
> _______________________________________________
> NCLUG mailing list NCLUG at lists.nclug.org
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://lists.nclug.org/mailman/listinfo/nclug