[dns-operations] comcast.net DNSSEC validation issues

[Mark Andrews]

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