DNS Flag Day

Mon Jan 21 00:40:51 UTC 2019

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 at 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 at 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 at 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 at 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 at radel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4177 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20190120/24378d31/attachment.bin>