[dns-operations] comcast.net DNSSEC validation issues

[Feldman, Mark]

I have to admit to reading the qname starting at the haughtington label
and ignoring the trash to the left.  My bad.  Your and Rob's follow-up
emails on and off list clarified this.

Agreed that there are many subtleties.  Would a non-DNSSEC-aware-resolver,
being asked for DS by a client, possibly accept responses from either the
child or parent depending on whether the NS set for the child was already
cached?  Not that this is germane to the question at hand since I think
we're talking about DNSSEC-aware systems throughout...

  Mark


On 6/22/17, 10:33 AM, "Mark Andrews" <marka at isc.org> wrote:

>
>In message <D57121D7.B642D%Mark_Feldman at cable.comcast.com>, "Feldman,
>Mark" writes:
>> Hi, Rob.  Feel free to provide me your additional details off-list.
>> Funny thing is that we don't have a haughtington.comcast.net subdomain
>>(or
>> label), so you should get NXDOMAIN there.  DS queries go to the parent,
>> which for comcast.net would be the .net name servers.
>
>Where DS queries go is much more subtle than that.  A DS query for
>gmail.com:\032haughtington.comcast.net will go to the servers for
>comcast.net.  For com:\032haughtington.comcast.net it will go to
>the servers for comcast.net.  For comcast.net will go to the servers
>for net if the client is DNSSEC aware otherwise they will go to the
>servers for comcast.net.
>
>The servers for comcast.net can also get query for DS comcast.net
>if they were also serving the root zone and that query needs to be
>answered from the comcast.net zone.  The client will detect that
>this is a grandparent / grandchild relationship and discover the
>servers for the intermediate zone and ask them for the DS record.
>Normally this issue happens deeper in the tree.
>
>These rules are complicated but they allow both DNSSEC and non-DNSSEC
>aware clients to get a answer for a DS query at the zone name.
>
>Also the second label was "com:\032haughtington".  The query was
>most probably generated because someone cut and pasted
>"gmail.com: haughtington.comcast.net" into a dialog box. '\032' is
>how you encode a space into a DNS label.
>
>Mark
>
>> We haven't touched
>> KSKs/DS records in quite some time.  It would be interesting to know if
>> others are seeing this 1) at all, 2) with BIND, and 3) with any other
>> validating resolver.
>>
>>   Mark
>>   Comcast Core INfrastructure Services -- we do DNS and more!
>> 
>> 
>> On 6/21/17, 6:13 PM, "dns-operations on behalf of Rob Foehl"
>> <dns-operations-bounces at dns-oarc.net on behalf of rwf at loonybin.net>
>>wrote:
>> 
>> >For the last week or so, I've had a pair of resolvers that are
>>repeatedly
>> >getting insecure or otherwise invalid responses from the authoritative
>> >servers for comcast.net, resulting in bad cache entries for comcast.net
>> >DS 
>> >records (invalidating the whole tree) on BIND 9.9 and SERVFAILs for
>> >specific triggering queries on 9.10.
>> >
>> >This was originally narrowed down to one query:
>> >
>> >gmail.com:\032haughtington.comcast.net DS
>> >
>> >Flushing the cache was sufficient as a temporary fix.  Today, I had a
>> >dozen resolvers across the US all do this, without similarly odd
>>queries
>> >having been seen.  This persisted for several hours, regardless of
>>cache
>> >flushes; any subsequent query for comcast.net would result in bad cache
>> >entries.  It mostly cleared up a few hours ago, but I've had a few
>> >recurrences since.
>> >
>> >Would anyone from Comcast mind taking a look at this, if you're not
>> >already aware?  I have packet captures of offending traffic and plenty
>>of
>> >logs, happy to share whatever you need to see.
>> >
>> >Thanks,
>> >
>> >-Rob
>> >_______________________________________________
>> >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
>> >
>> 
>> 
>> _______________________________________________
>> 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
>-- 
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>