[dns-operations] Anyone with contacts at Paypal and/or Ultradns?

Wed Dec 11 18:48:02 UTC 2019

On Wed, Dec 11, 2019 at 06:06:08PM +0100, Tom Ivar Helbekkmo wrote:

> Viktor Dukhovni <ietf-dane at dukhovni.org> writes:
> 
> > A word of unsolicated advice (you're more than free to ignore) from
> > someone (me) deeply enmeshed in email security and DNSSEC:
> 
> Thanks, Viktor!
> 
> >     * Don't use qname minimization with validating MTA-facing resolvers.
> >     * Instead run a *local* resolver.  The cache on that resolver will
> >       do all the qname minimization you can get.
> 
> I do run a local recursor, so yeah, I see what you mean.  However, it
> turns out that I need to turn off DNSSEC validation, too, to get the
> recursor to accept the name servers from Ultradns; their mishandling of
> those ENTs trips up the validation, which fails.

Let's see whether that's necessary.  Indeed with qname minimization,
you'd run into issues (answers below are stripped of RRSIGs to save
space).

First the MTA name parent ENT, which does not come into play once you
turn off qname minimization:

  * Good:
    @ns1.p57.dynect.net.[208.78.70.57]
    @ns2.p57.dynect.net.[204.13.250.57]
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35708
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;slc.paypal.com.                IN NS
    paypal.com.             SOA     ppns1.phx.paypal.com. hostmaster.paypal.com. 2012279282 7200 600 1209600 300
    siplb.paypal.com.       NSEC    mx-ma1.slc.paypal.com. A RRSIG NSEC

  * Bad: No NSEC RRs to validate the ENT NODATA.
    @pdns100.ultradns.com.[156.154.64.100]
    @pdns100.ultradns.net.[156.154.65.100]
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54453
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
    ;slc.paypal.com.                IN NS
    paypal.com.             SOA     ppns1.phx.paypal.com. hostmaster.paypal.com. 2012279282 7200 600 1209600 300

Next the MTA A records (valid signed answer across all the nameservers):

    @ns1.p57.dynect.net.[208.78.70.57]
    @ns2.p57.dynect.net.[204.13.250.57]
    @pdns100.ultradns.com.[156.154.64.100]
    @pdns100.ultradns.net.[156.154.65.100]
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56730
    ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 1
    ;mx-ma1.slc.paypal.com. IN A
    mx-ma1.slc.paypal.com.  A       173.0.94.245

Next the DKIM key ENT:

  * Good:
    @ns1.p57.dynect.net.[208.78.70.57]
    @ns2.p57.dynect.net.[204.13.250.57]
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17089
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;_domainkey.paypal.com. IN NS
    paypal.com.             SOA     ppns1.phx.paypal.com. hostmaster.paypal.com. 2012279282 7200 600 1209600 300
    _token._dnswl.paypal.com. NSEC  1sfdc._domainkey.paypal.com. TXT RRSIG NSEC

  * Bad: No NSEC RRs
    @pdns100.ultradns.com.[156.154.64.100]
    @pdns100.ultradns.net.[156.154.65.100]
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41560
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
    ;_domainkey.paypal.com. IN NS
    paypal.com.             SOA     ppns1.phx.paypal.com. hostmaster.paypal.com. 2012279282 7200 600 1209600 300

Next a (signed) DKIM key TXT record, which is also fine across all the
nameservers:

    @ns1.p57.dynect.net.[208.78.70.57]
    @ns2.p57.dynect.net.[204.13.250.57]
    @pdns100.ultradns.com.[156.154.64.100]
    @pdns100.ultradns.net.[156.154.65.100]
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8259
    ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 1
    ;1sfdc._domainkey.paypal.com. IN        TXT
    1sfdc._domainkey.paypal.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

By way of contrast, querying for the TLSA records of Paypal's inbound
MTAs (MX hosts), which live under paypalcorp.com, works with or without
qname minimization:

    @ns1.p57.dynect.net.[208.78.70.57]
    @ns2.p57.dynect.net.[204.13.250.57]
    @pdns100.ultradns.com.[156.154.64.100]
    @pdns100.ultradns.net.[156.154.65.100]
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32943
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;_tcp.mx1.paypalcorp.com. IN NS
    paypalcorp.com.         SOA     ppns1.phx.paypal.com. hostmaster.paypal.com. 1969010819 7200 600 1209600 60
    mx1.paypalcorp.com.     NSEC    mx2.paypalcorp.com. A RRSIG NSEC

    @ns1.p57.dynect.net.[208.78.70.57]
    @ns2.p57.dynect.net.[204.13.250.57]
    @pdns100.ultradns.com.[156.154.64.100]
    @pdns100.ultradns.net.[156.154.65.100]
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28243
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;_25._tcp.mx1.paypalcorp.com. IN        TLSA
    paypalcorp.com.         SOA     ppns1.phx.paypal.com. hostmaster.paypal.com. 1969010819 7200 600 1209600 60
    mx1.paypalcorp.com.     NSEC    mx2.paypalcorp.com. A RRSIG NSEC

So the UltraDNS servers look generally capable of handling ENTs,
and the issue appears to be somewhat specific to the paypal.com
zone.

> A quick exchange on the PowerDNS IRC channel (I'm using their most
> excellent software) helped me understand what was going on, and I ended
> up configuring my recursor to avoid querying the Ultradns name servers.

That may be prudent anyway, but it looks like avoiding qname
minimization would be sufficient to avoid at least the more obvious
issues.  If you disable qname minimization and flush your cache, it
would be interesting to learn what issues you still see after that,
assuming you're willing to re-enable the ultradns servers long enough to
perform a test.

-- 
    Viktor.