Date: Sun, 20 Jan 2019 18:40:20 -0500 From: Jon Radel <jon@radel.com> To: freebsd-questions@freebsd.org Cc: Daniel Feenberg <feenberg@nber.org> Subject: Re: DNS Flag Day Message-ID: <5522b94d-4529-e10e-db65-20a1c172d46a@radel.com> In-Reply-To: <alpine.BSF.2.21.9999.1901201548260.40690@mail2.nber.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 1/20/19 15:49, Daniel Feenberg wrote: > > Is DNS Flag Day something that should concern someone using FreeBSD 11.2 > for name service? I ran the tester at: > > https://dnsflagday.net/ > > and it indicated a need for concern, but the details were > unintelligible and there was no suggestion of "what to do". Not enough details are provided by you in the above to have a clear answer. Are you using the FreeBSD 11.2 server as an authoritative server for one or more DNS zones? (You don't give any hint as to whether you are using it for a recursive server, an authoritative server, or both.) Are there other authoritative servers involved? Are you running a firewall or firewalls that mess with EDNS packets? Bottom line appears to be that if you have one or more authoritative servers which don't implement certain aspects of EDNS properly the life of people trying to resolve the contents of your zone will start to degrade more quickly in a bit over a week. So who runs your authoritative DNS servers? ---------- If the zone you are worried about is nber.org [as an aside, this business of being freaking coy about what domain you're talking about and what the "need for concern" actually is achieves very little other than wasting the time of people attempting to answer your question--you're publishing this stuff to the world in DNS, IT IS NOT A SECRET!], then the test at https://ednscomp.isc.org/ednscomp/ gives the result > > Checking: 'nber.org' as at 2019-01-20T23:12:14Z > > nber.org. @66.251.72.1 > (ns1old.nber.org.): *dns=timeout* *edns=timeout* *edns1=timeout* *edns@512=timeout* *ednsopt=timeout* *edns1opt=timeout* *do=timeout* *ednsflags=timeout**docookie=timeout* *edns512tcp=timeout* *optlist=timeout* > > nber.org. @198.71.6.1 (ns1.nber.org.): dns=ok edns=ok edns1=ok > edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok > docookie=ok,cookie edns512tcp=ok optlist=ok,expire,cookie,subnet > > nber.org. @198.71.6.3 (ns3.nber.org.): dns=ok edns=ok edns1=ok > edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok > edns512tcp=ok optlist=ok > > nber.org. @64.112.178.60 (ns1.basespace.net.): dns=ok edns=ok edns1=ok > edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok > edns512tcp=ok optlist=ok > > which indicates that there are 4 authoritative DNS servers for nber.org found by that test, 3 of which appear to be fine (all tests are "ok") and 1 of which doesn't answer at all (all tests "timeout"). Digging a bit further shows that you've got a delegation of 3 nameservers at your parent (that's driven by what you tell your domain registrar): nber.org. 86400 IN NS ns1.basespace.net. nber.org. 86400 IN NS ns3.nber.org. nber.org. 86400 IN NS ns1.nber.org. h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB H9PARR669T6U8O1GSG9E1LMITK4DEM0T NS SOA RRSIG DNSKEY NSEC3PARAM h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN RRSIG NSEC3 7 2 86400 20190210232117 20190120222117 45404 org. USaVbdxbrfaLzm+YzPfAvPE1SBUqU7wWBohEn//1h8ieDHy/ss2n35+K ZpHlToowfaC63D+EvQDVjNz1we2DXRLGSFChKNtpfVTBg7vjehznwpml JuxyY3EmRwchgIBs5sfQjJBx3NdqIaSthpEXqTYoFHMlIRX4zJqzMBv8 Gtg= 3uqemnrnh81uabs2702d7fq097q7aanc.org. 86400 IN NSEC3 1 1 1 D399EAAB 3UQSUQNPC70J298TT0MJ82F98PLD7MD8 NS DS RRSIG 3uqemnrnh81uabs2702d7fq097q7aanc.org. 86400 IN RRSIG NSEC3 7 2 86400 20190207152537 20190117142537 45404 org. QKUZwTKC1Nz1L8P39RYWHDsdwSNSAQlkIAA3rFTPBM2eYLrDozGj7yxx j4cMjQfjn7IOMsV+vQ/v/UpTU7A5GDATjaOzmcourwqJw0ZvJI7jq294 Tw6vJsyn1DIyH2pOdQDYBx1MijafvgXzeqbc32lfVLdrobj54dZhlCyI fHI= ;; Received 629 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 186 ms But at least one of the servers for the zone itself lists a greater number of nameservers: nber.org. 300 IN NS ns1.nber.org. nber.org. 300 IN NS ns3.nber.org. nber.org. 300 IN NS ns1.basespace.net. nber.org. 300 IN NS ns1old.nber.org. ;; Received 205 bytes from 64.112.178.60#53(ns1.basespace.net) in 24 ms one of which is apparently a pretty bad idea, given that it appears to be dead and gone. Even the name "ns1old" is pretty suggestive, what? So the solution would be to clean up the zone data and discard the NS record that refers to a server that doesn't exist. Note that I've not confirmed that the matching A records between the glue records at your parent and the records in the zone itself are consistent, in other words, I'd suggest checking that you've told the registrar the same thing that you've got in your DNS data and that that is the same thing that all servers involved are actually configured as. An alternate view at another test site that tests for a different set of things, but also catches your current issue: http://dnsviz.net/d/nber.org/dnssec/ That keeps historical records and shows that you've had this issue for over a year now. -- --Jon Radel jon@radel.com [-- Attachment #2 --] 0 *H 010 `He 0 *H 00Πj8;+kٸRV0 *H 01 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1+0)U"COMODO RSA Certification Authority0 130110000000Z 280109235959Z01 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA0"0 *H 0 W(vu@8v!P%y L}:X>1.4vلj=4HK hyt4z|e`'"2@rF5P3*UT+%4D5+ ZSu+=7F_Zte >) 94Fro8pNhFF#Ne6/M{UWֱmAYT"o)CI m84$.zW4 r^M9,R$ <080 U #0~=<8220 U la| =+qH^ċ0U 0U 0 0U 00U 0LU E0C0A?=;http://crl.comodoca.com/COMODORSACertificationAuthority.crl0q+e0c0;+0/http://crt.comodoca.com/COMODORSAAddTrustCA.crt0$+0http://ocsp.comodoca.com0 *H x\(4O<_VΟV쏢kI/5@qB !fk&kn{hJd| q[Lǿᓬ?"@fCOݐrX urJH5;#68jle) )Y4Nezyq{: kx%iچ:w#f6HLP~jo9KXnM#:!!6 9i\}^M;TSX7 ̯3]Tc6O$voX*5!4.aKE8HIĹ7? Ar}r# R/h<סnuy<1 3mɔv#~&p vg' skMH#/ƨ$/uX qTu(|^-vM҆NKX7fA\X5sh2qP\YǟENRarpGtZp _" k7Dd JVGz00Ԡt$a,w0 *H 01 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CA0 180304000000Z 210303235959Z01 0 UUS10 U221501 0 UVA10U Springfield10U 6917 Ridgeway Dr.10U Jon T. Radel1200U )Issued through Jon T. Radel E-PKI Manager1 0 U Corporate Secure Email10U Jon Radel1 0 *H jon@radel.com0"0 *H 0 LNuOpS#OfK!UdYo /Ǡ8,K +3ڄdI̓ h3f8\/9N 6(6/FY~˩ I¯ .~1$#DT] ~8҄YO7+8b °$aEr]bW8ECIGJZ tTK 5ڈhӎڀ6Pc 3=dEH 00 U #0la| =+qH^ċ0 U t ZI&Ҝ0U 0 U 0 0 U %0++0FU ?0=0; +10+0)+ https://secure.comodo.net/CPS0ZU S0Q0OMKIhttp://crl.comodoca.com/COMODORSAClientAuthenticationandSecureEmailCA.crl0+0}0U+0Ihttp://crt.comodoca.com/COMODORSAClientAuthenticationandSecureEmailCA.crt0$+0http://ocsp.comodoca.com0U 0 jon@radel.com0 *H T4iYDP#3oN]k|QϵH2q-®%WK0P3c[7Г<w'A\|MkY&~X;# `+;ok&I sݕ?CfpHwg2 5A~=f|M~^=ArZSYQ-4A;֎n9hEkh l^}Ky2B|(T]:1501001 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CAt$a,w0 `He Y0 *H 1 *H 0 *H 1 190120234020Z0/ *H 1" R QYFX B chmLW?.0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CAt$a,w0 *H 101 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1=0;U4COMODO RSA Client Authentication and Secure Email CAt$a,w0 *H o> RagF\I\:B:?߂~tn9i$~0Ό}\wt~KD"zhΌma NVc& cZ_ c[٬Ŝ L f CѰxX<pl_YXYaS)q\IQ6Ӣ,GFkXEr iF~ѪF Y' `:Q OA+3x E(8"XC8 0home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5522b94d-4529-e10e-db65-20a1c172d46a>