[dns-operations] Nameserver responses from different IP than destination of request

[Rich Goodson]

Back when I used to manage caching iterative resolvers for a large cable concern I used to see stuff like this all the time.  

Queries sent to one of the servers in an NS RR set of 3 would come back from a different IP (sometimes the same IP as one of the other name servers in the NS RR set). The resolver just drops the response and sends a query to one of the other servers that responds appropriately.  

Or the glue records and the NS RR set only partially overlap, and the servers that are different give different answers.  

Or the servers in the NS RR set don't have matching A records, so resolution works fine for X time (because we can get there the first time via the glue records), then fails for Y time (the difference in time between the expiry of the glue A records and the expiry of the longer TTL of the NS records for the zone).  

Or whatever.  There are a great many creative misconfigurations out in the world that cause problems but don't lead to outright resolution failure and some that lead to intermittent failures, but "hey, our servers are still getting traffic, so it can't be a problem with our DNS".

I will say that Mark's initial answer really resonated with me, however.  It was always super annoying when the ticket would contain "it works when I look it up on Google/OpenDNS/Whatever".  Sometimes that would be because it was a problem of the intermittent variety, and sometimes because another operator was using different software.  But my goal at that job was simply to make the noise stop (close the ticket), so if that involved creating a local A record for a large bank whose NS records pointed to CNAMES that were periodically unresolvable I would do it and make a reminder in my calendar to check on it once a month or so to see if/when I could remove it.

Just my experience from an operations perspective.

Rich

> On Aug 31, 2020, at 1:19 PM, Warren Kumari <warren at kumari.net> wrote:
> 
> On Mon, Aug 31, 2020 at 2:11 PM Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>> * Puneet Sood via dns-operations:
>> 
>>> We would be interested in hearing other operator's experience here.
>>> Are recursive servers seeing similar behavior from authoritative
>>> servers? If yes, are you discarding these responses?
>>> Are there authoritative server operators who still need the
>>> flexibility afforded by RFC 1035?
>> 
>> If I recall correctly, while helping to run an academic network I
>> encountered this issue on the authoritative server side.  That was
>> close to twenty years ago, and even back then, it did not occur to us
>> to push the resolvers to accept these incorrectly sourced responses,
>> instead of getting the authoritative server operator to fix their
>> setup.
> 
> The bit that I'm failing to understand is why these continue to exist
> -- if everyone (or, everyone other than Google) are ignoring /
> dropping these, how / why are they still on the Internet? Is it just
> the $whatever are sending these are always deployed next to something
> that ain't broke and the operator just hasn't noticed?
> Or are perhaps more things accepting these than we expect?
> 
> W
> 
>> Or maybe I'm not correctly remembering things, and it wasn't
>> DNS but Sun RPC.  (Hard to believe that even early BIND 4 didn't get
>> this right, and what else could they have been running?)
>> 
>> Anyway, in my current world, most recursive DNS servers operate behind
>> some sort of stateful packet filter, so the server operators on their
>> own cannot make these incorrectly source responses work because the
>> systems under their direct control never receive them.
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations