[NCLUG] Carputer / Megasquirt

seanrees at gmail.com seanrees at gmail.com
Thu Oct 14 08:14:16 MDT 2010


Wow, major FAIL on msefi.com.


-sr.
(now in dublin, ireland.)

On Thu, Oct 14, 2010 at 2:36 PM, 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
>



More information about the NCLUG mailing list