[dns-operations] DNSSEC validation - salliemae.com

[Scott Morizot]

It's not broken in unbound. He was using the ODVR unbound instance in his
examples, which I also tested against. And I have some unbound based
systems at work.

https://www.dns-oarc.net/oarc/services/odvr

As I and others illustrated in the dnsviz.net results, www.salliemae.com
validates properly as a secure alias pointing to a secure target. The A
records for salliemae.com also validate properly. Other records and
responses *are* broken. As others have mentioned I'm also curious how they
managed to break portions of their zone in such an odd way. But the issue
resolving an A record for salliemae.com and for www.salliemae.com in your
deployment of unbound indicates something else is also at play that appears
specific to your recursive nameserver deployment, not to unbound generally
for at least the A records for those two specific names. Those should
validate properly and return results, not a SERVFAIL. And they do
everywhere I can check. So that indicates a different issue for that
portion of your results.

On Thu, Aug 8, 2019 at 1:34 PM Robert Blayzor <rblayzor.bulk at inoc.net>
wrote:

> On 8/8/19 2:07 PM, Joe Abley wrote:
> > I get a response with a signature:
> >
> > [anchovy:~]% dig @184.105.193.74 salliemae.com IN A +dnssec +multiline
>
>
> I think it was more my point is that their NS records and SOA records
> return a bad signature and hence SERVFAIL.
>
> I would probably expect that to cause all kinds of other problems;
> perhaps thats the reason why it's broken in unbound.
>
> This is the only domain I'm having a problem with with unbound
> resolving. Like I said, in unbound I'm sometimes getting a timeout and
> other times just getting a SERVFAIL.
>
>
> --
> inoc.net!rblayzor
> XMPP: rblayzor.AT.inoc.net
> PGP:  https://pgp.inoc.net/rblayzor/
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190808/a8ef0be9/attachment.html>