[dns-operations] 2600::a1 (ns1-auth.sprintlink.net)

[Gonzalo Muñoz]

It looks like the sprintlink NS has a problem with DNS cookies. Using
dig 9.11.0-P1:

$ dig @ns1-auth.sprintlink.net. ups.com mx
(...)
;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 14540
(...)

$ dig @ns1-auth.sprintlink.net. ups.com mx +nocookie
(...)
;; ANSWER SECTION:
ups.com.		300	IN	MX	10 email-vip.ups.com.
ups.com.		300	IN	MX	10 email2-vip.ups.com.
(...)


- Gonzalo

On 16/02/17 16:05, Jim Popovitch wrote:
> On Thu, Feb 16, 2017 at 1:56 PM, David C Lawrence <tale at akamai.com> wrote:
>> Jim Popovitch writes:
>>> ~$ dig MX ups.com @ns1-auth.sprintlink.net
>>> ...
>>> ;; WARNING: recursion requested but not available
>>> ....
>>>
>>> I'm not always in the loop on things like this, how common is that?
>>
>> Extremely.  By default dig asks for recursive resolution, and it has
>> no sense whether the target @server is a resolver or authoritative
>> server.  Most authoritative servers are properly not configured to
>> allow recursion, so when the answer comes back without the recursion
>> available flag set dig just makes a note of that.
>>
>> You can use dig +norec to turn off the recursion desired flag in the
>> query, and that will make the warning go away.
> 
> 
> The issue is less about the norec, and more about the sprintlink NS
> servers (listed as the auth NS servers for ups.com) not returning RRs.
> 
> -Jim P.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>