tobez / validns Goto Github PK
View Code? Open in Web Editor NEWDNS and DNSSEC zone file validator
License: Other
DNS and DNSSEC zone file validator
License: Other
Hello,
We would be very grateful if you are willing to release a 0.4 of validns (with the ECC support).
Merci
Via Daniel Stirnimann:
If so, then it might make sense to not consider this an error at all
(or maybe add a policy check that will make such cases into errors,
thus allowing the operator the degree of control you suggest, effectively).
Do you still plan on implementing INCLUDE? If not, would it be possible to (add an option to) ignore INCLUDE statements?
validns currently only supports checking the zone file against a single time stamp. By default, validns checks the expiration and inception time against "now". However, using the parameter '-t epoch-time' one can provide a time in the future or the past.
It seems like a trivial fix to me, to allow more then one time parameter to be given on the command line.
e.g. validns -t epoch-time -t epoch-time zone-file
The signatures expiration and inception time stamps would then be checked against all provided time parameters from the command line. The advantage is that this allows for more advanced time checks. For example, my zone file contains signatures with the inception time of at least now-1h. The expiration time is at least now+2weeks or up to now+3weeks.
Before publishing a zone, I could check my zone with:
validns -t -t <now+2weeks> zone-file
to make sure that the signing worked as expected. With the current implementation, I would need to run validns twice. However, given that my zone files are quite large, I rather run validns only once!
Requested by Daniel Stirnimann:
Nonetheless, I think in the long term it could still make sense to
provide the granularity of different error levels such as ERROR, WARNING
and maybe INFO. For example: you have a buggy signer which leaves some
old RRSIGs by accident and your zone is not in an algorithm key rollover
state as described above. The operator has enabled the above new policy
check because some of his zones do have an algorithm key rollover at one
point in time. Without providing different error levels, the operator
will not detect this failure in the buggy signer.
Maybe you could just log such situations in the "verbose" output so that
an operator has the chance to detect them. Current verbose logging would
be marked as INFO and more serious none-errors could be marked as WARNING.
(Via Paul Woters):
I just encountered a bug in validns.
Image the zone:
example.com. IN SOA .......
example.com. IN NS ns1.example.com.
ns1.example.com. IN A 1.2.3.4
backoffice.toronto.example.com. IN NS ns1.backoffice.toronto.example.com.
ns1.backoffice.toronto.example.com. IN 3.4.5.6
www.example.com. IN A 5.6.7.8
When this zone is signed, validns gives an an error about missing
NSEC(3) records for "toronto.example.com".
I think there is a wrong assumtion in the code that any "." means a
zone cut with NS/A/AAAA records. This assumption is incorrect :)
Reported by Daniel Stirnimann,
commented on by Willem Toorop.
Validns canonicalizes NSEC RDATA. The common practice for bind and unbound is to not do it:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-19#section-5.1
5.1. Errors in Canonical Form Type Code List
When canonicalizing DNS names (for both ordering and signing), DNS
names in the RDATA section of NSEC resource records are not
downcased. DNS names in the RDATA section of RRSIG resource records
are downcased.
The guidance in the above paragraph differs from what has been
published before but is consistent with current common practice.
[RFC4034] Section 6.2 item 3 says that names in both of these RR
types should be downcased. The earlier [RFC3755] says that they
should not. Current practice follows neither document fully.
Therefore, validns behavior must be changed to reflect the current practices.
The following files needs to be removed when cleaning:
Validns fails to validate RRSIGs for CAA-records. The CAA-record itself validates fine and the RRSignature seems ok as well. NSD, Unbound and dig have no problem serving and retrieving the records which strongly suggests that the RRSIG is correct.
$ ./validns -z mijnuvt.nl /tmp/mijnuvt.nl
/tmp/mijnuvt.nl:12: mijnuvt.nl. RRSIG(CAA): bad signature
$ grep CAA /tmp/mijnuvt.nl
mijnuvt.nl. 3600 IN CAA 0 issue "digicert.com"
mijnuvt.nl. 3600 IN RRSIG CAA 8 2 3600 20170817111032 20170803134224 40935 mijnuvt.nl. ZU5S/KK5Nl0XKHbCjhHC7Iacbsm1CrCA2AjKfGaw0XojCrWOJjMq2UvjVrZsDAsvyjeLBpfqvpTDyLHCin/xxHSP455e8skRcvDovpEmhHNoUcYKIQLOFTy6acAuzAyUbZ5vJAgzga4vayFKaaHcJqL+9Zm0avDb00fZRBoB+mw=
71cmi5a5nrv504hcc2rglvu6mjgqejhg.mijnuvt.nl. 3600 IN NSEC3 1 0 5 279cca9209a3eec3 91k63cl5l58cdttq946f1ck8e2t3uim6 SOA TXT RRSIG DNSKEY NSEC3PARAM CAA
$ dig +short +dnssec -t CAA mijnuvt.nl @ulam.uvt.nl
0 issue "digicert.com"
CAA 8 2 3600 20170817111032 20170803134224 40935 mijnuvt.nl. ZU5S/KK5Nl0XKHbCjhHC7Iacbsm1CrCA2AjKfGaw0XojCrWOJjMq2Uvj VrZsDAsvyjeLBpfqvpTDyLHCin/xxHSP455e8skRcvDovpEmhHNoUcYK IQLOFTy6acAuzAyUbZ5vJAgzga4vayFKaaHcJqL+9Zm0avDb00fZRBoB +mw=
$ git rev-parse HEAD
eb71f3620c76612f02c07695a757514188891858
I get an error:
% validns -p all -z example example.signed-text
example.signed-text:15: example. RRSIG(TYPE65534): bad signature
example.signed-text:3: example. RRSIG(SOA): bad signature
The zone is maintained by BIND "auto-dnssec maintain;" feature (auto-signing). Since the signed zone is in binary format, I extracted it with:
named-compilezone -j -i none -f raw -F text -o example.signed-text example example.signed
Is it a bad procedure? A bug in BIND? In validns?
The actual zone file is in https://gist.github.com/bortzmeyer/6105081
And possible other RR types.
I get a lot of NSEC validation problems while testing the .se zone now, example:
/home/pawal/antispam/se.new:10184434: NSEC says xn--ulrikskldblogg-dib.se. comes after xn--ulriksfrskringsblogg-jzb70b.se., but a.ns.xn--ulriksfrskringsblogg-jzb70b.se. does
/home/pawal/antispam/se.new:10184443: NSEC says xn--ultraljudsskrmma-7nb.se. comes after xn--ulrikskldblogg-dib.se., but a.ns.xn--ulrikskldblogg-dib.se. does
This is the content of the zone file:
xn--ulriksfrskringsblogg-jzb70b.se. 7200 IN NSEC xn--ulrikskldblogg-dib.se. NS NSEC
RRSIG
xn--ulriksfrskringsblogg-jzb70b.se. 86400 IN NS a.ns.xn--ulriksfrskringsblogg-jzb70b
.se.
a.ns.xn--ulriksfrskringsblogg-jzb70b.se. 86400 IN A 178.73.224.237
xn--ulrikskldblogg-dib.se. 7200 IN RRSIG NSEC 5 2 7200 20111110080515 (
20111027170504 33951 se.
QzarSfVI7VknY1PxQEO0ySkhpPoKg7BbzilsyoMVofVpH
DA11Vsn2alwuaQkx6vxu2W1C2RyolEJG8fSmO8A4cxd9q
EkWNoDJK8frkiN2PuCY3uI1u+BIiX1rxbVZO+qqk05hFr
o6szHzZNtlmlWSoqaRedkf3h4i4iU0S/rudY= )
xn--ulrikskldblogg-dib.se. 7200 IN NSEC xn--ultraljudsskrmma-7nb.se. NS NSEC RRSIG
xn--ulrikskldblogg-dib.se. 86400 IN NS a.ns.xn--ulrikskldblogg-dib.se.
a.ns.xn--ulrikskldblogg-dib.se. 86400 IN A 178.73.238.252
xn--ultraljudsskrmma-7nb.se. 7200 IN RRSIG NSEC 5 2 7200 20111111210454 (
20111029190504 33951 se.
J7MVJJhqYq/6GC53Pf2vmVLZI2XiRaPKvQY8oi7Y7OyxV
f0avF6SrLaJ4+IMLUCVK+sV3Q2XyRPN7nnlib9BiTglaM
QHsgdAujduQY4n35cl57p3rPwMmJIdScv0OZnWPQU1IIM
GtpkIJqGZMLcC5/+P2WXCOTtXph2y/ArkgkM= )
xn--ulriksfrskringsblogg-jzb70b.se. has been delegated (with the NS) so therefore a.ns.xn--ulriksfrskringsblogg-jzb70b.se is glue that should not be covered by NSEC.
See RFC 4034 section 4, and 4.1.1:
Owner names of RRsets for which the given zone is not authoritative
(such as glue records) MUST NOT be listed in the Next Domain Name
unless at least one authoritative RRset exists at the same owner
name.
Hi. I'm having a validns error in a zone with a LOC RR signed with algorithm 7. The error is
vulcano.cl.signed:73: vulcano.cl. RRSIG(LOC): cannot verify the signature
The zone is signed with bind tools and validate correctly in the live zone.
I hunted down the error to EVP_VerifyFinal, so may be my openssl version (OpenSSL 1.0.0e-fips 6 Sep 2011)?
Changing the algorithm to 5 (like the example.sec.signed test file) works ok.
I've opened AXFR for the zone in ns.vulcano.cl, if you need it.
Thanks,
Hugo
With this zone :
1-wire.fr. 43200 IN SOA ns1.absolight.net. root.absolight.com. 2013071502 86400 3600 604800 600
1-wire.fr. 43200 IN RRSIG SOA 7 2 43200 20130722150717 20130715135031 54587 1-wire.fr. C0TMxMsWPT7BpJk4l+Ad1MOGEEMUenyXrjz+JvEmUi4vEUFFsioG5aL4eXCvHGGgA8UQqDo0ehgcvIbWQL27ewqUniI9ZKQiJL8JpAMiwXPKMf3dM9dx8a85hZOZn2jskqGUmAcBaEmVdMVO+g2GIhAyg/dueovvCEEvj5OPu7g=
1-wire.fr. 10800 IN DNSKEY 257 3 7 AwEAAbE2XO555dx58x7Dr+4fcheKI19lhdd3JwcySQ3Ej6Gg8TvB9yNJnT6dpj9ISspPUYlYgjFku/R7ILVlA2KBHCttP3b9UyERYczx6F5FHfROlvmn+fgvTYqPIQBv/Im1O+F1AEPqINPadY3BuOc4B3X7cC5PEpX+J2SWHrBimNSFKjQCxKdk+WVY84daJXbjUgCzc/qaQbnOpw0bg5PpmNLmiecQfTSHoKSdl/vXWwUxpAIEDGdY2ZLpPrF5bCbIhAS6j2D9ya9VnPPgGlg4KnDkFL9yEHgciPHqkNzjcC/7qumjFJ5W9vhiRy8CeOrGMGpRXVzGU2QKtVp1clslVfs= ;{id = 26548 (ksk), size = 2048b}
1-wire.fr. 10800 IN DNSKEY 256 3 7 AwEAAa/kxQu4uWyLW+O47FetO7W6ir9G0MbmCZTaXuaKxNGOyA6JNvOnyuQLRgYSldzDI3y0m5dxSG0GCtAED7uvhIzO6aQt8RS2Jl6USYLR8ih/tT8xcU185rssP06xzjWs5U/BklBTSEdCeBdrIOqA03N4c8E1k4LXh/We8WGoN0c1 ;{id = 61635 (zsk), size = 1024b}
1-wire.fr. 10800 IN DNSKEY 256 3 7 AwEAAaFgYm3yv4AfK6wWuBKzqI6WEW/vbNPtVho6hyAjEIsGCnoDft7hxcqcaNm+7CNSi99WIC5m//Cxh1Lx0wyMytI7ttvGsCpoYtvDwf6P656kxoaAIGhyHMJq3Y8JrbR69+XagQlDBeHt3GMzeytMSGD3nOl3b1B7yEkrSooLGDXh ;{id = 54587 (zsk), size = 1024b}
1-wire.fr. 10800 IN RRSIG DNSKEY 7 2 10800 20130722151334 20130715134757 26548 1-wire.fr. ccA00mtHbD4BhFc+YxhVMpD+oB+m+Q0Es+YgIiAOcNcfsd33r5WM8IChV9IIFqUZ8uH2ehdMNadc9Kue0HJsTzjhp5DAJ2tgIDOIKU8jzuExLDuk/EvSE48z7fZMlncyrOv1DBpri+Rs7ePtDQjdiTuBejFEUirlBCCzhMvOuFQTQhnkKs+ZbR1Ei4NCyfcoPR3mJzsl7h5aa54E7MzaeVL3uhOBHezorbLSaqX+khmuQCbGgHNplMN7YxKhhihHQHASqQHc4BGka/ZR0eL4aNAu91kfDCMgbSGXd8YWFD7RayUMIoG3DXBd2I9zmIO8sRBuHbhd8WDO38SFrk50EQ==
1-wire.fr. 0 IN NSEC3PARAM 1 0 100 a6b05497e26b2e5a
1-wire.fr. 0 IN RRSIG NSEC3PARAM 7 2 0 20130722102802 20130715134757 54587 1-wire.fr. M/IGI7xR7lkik1tOj8s9nfAfUFjAlBMJ8OoWxjTQNpyFUrHLs0UsKPIfJwTcva2KLXw3/lw6k9MHe6eUD61AGptU34vXhFDcZgrgh5jEMHZyguyfFYVXI50WrXR7jEUpEL/+CGso4KPYAS0lqThlYWn5qci8Pwuu+CGOiO9CrNU=
1-wire.fr. 86400 IN NS ns1.absolight.net.
1-wire.fr. 86400 IN NS ns2.absolight.net.
1-wire.fr. 86400 IN NS ns3.absolight.net.
1-wire.fr. 86400 IN NS ns4.absolight.net.
1-wire.fr. 86400 IN RRSIG NS 7 2 86400 20130722192629 20130715134757 54587 1-wire.fr. UQ3ZXu2FKM+MK4pL++4jFSzU5y9JTQ5uZAo+iZJs61KIjpGuUepcAqsSsLQ7kkInJC6WwLs+HP1Rf9vdZJT1/bXQ3idzjCdFvC8GgOWQ26/9o4eZaosOu6GZDJ8yr8A4D1MwWCATnCir+Aodp0VXFLTrUULa8yzNICYc1wje7nw=
1-wire.fr. 86400 IN A 193.30.224.226
1-wire.fr. 86400 IN RRSIG A 7 2 86400 20130722140635 20130715134757 54587 1-wire.fr. Ac8kVc8a7F7NZfq1HjpokUSbMmvdiEtSSnC7F6+ZZ1PkKKlr1tcTrxgin3HPWx/A41bwaSjA5gCddpGILBPKgvDHREEviGqfHjYycC4Z3c/o3aoKhFmAKWkD7vr7B+RdNMwZ383HmaGESTU4JT6y01Hxby1xxORJn7xXt8B2hVg=
1-wire.fr. 86400 IN MX 10 mx3.absolight.net.
1-wire.fr. 86400 IN MX 20 mx4.absolight.net.
1-wire.fr. 86400 IN RRSIG MX 7 2 86400 20130722053332 20130715134757 54587 1-wire.fr. IrNybnP6OevPYdIQRiBZhREaHbVi3x2g5Zpe72/3C7vajc0pDDHyy6ardXXbikGCfsNWvZJk2k4XDlhFjUsjRtRqzMskAqRggKsBFSRUFn1XW2Pqlb0jAXpBNRPNs1mlAHQpAirADCZvUSyT0yDO9nwPo7Si0uJ/i9OiHzQGxvk=
rbbkes60aq8v8tj8993u9jc7g0nnvmkd.1-wire.fr. 600 IN NSEC3 1 0 100 a6b05497e26b2e5a 3tok8i9ahpvn7voas6f25dbnlcrkt32m A NS SOA MX RRSIG DNSKEY NSEC3PARAM
rbbkes60aq8v8tj8993u9jc7g0nnvmkd.1-wire.fr. 600 IN RRSIG NSEC3 7 3 600 20130722090734 20130715134757 54587 1-wire.fr. nSJmsfyObrzSu9xxjwnyt9ZVy/R9wCcKruDpKCWiSXaNkwrGnNBvFFctSWoUdtixX0BAwlOfuLjwhjkyetZJEXqR+TD8t2002ol/FjjzgTY7jrfORgQ0mZKmKNQKT/gu9Px5k/uI9fihoAuYMZxFJpqQuRiIculyciz61bx+yjM=
_keyword.1-wire.fr. 86400 IN TXT "$Abso: 1-wire.fr,v efbe6fe0d5af 2013/07/15 14:00:27 mat $"
_keyword.1-wire.fr. 86400 IN RRSIG TXT 7 3 86400 20130722081009 20130715135031 54587 1-wire.fr. BN0Njs/7Xl0/dU/kjt50dwL8gmoEFolsCHf+CLsHwD/JbR7aJVbn34QcjCS/HGVSbjm/0phIrMCNHA6QndllzWpQ948RKD3qdEUpRFfe+v1f8qxMSkkWjpFpZgse4zX10PuiM8WSvr21j3x69s2KJhMSz0I9Y4z/wIPBl/STQ3o=
51a6th45ca1hnfa540p77t6d79flpfnj.1-wire.fr. 600 IN NSEC3 1 0 100 a6b05497e26b2e5a fui5h4nkfd427prmp83unqg52ah4ecs5 TXT RRSIG
51a6th45ca1hnfa540p77t6d79flpfnj.1-wire.fr. 600 IN RRSIG NSEC3 7 3 600 20130722052351 20130715134757 54587 1-wire.fr. FCV9sYwaq//Uyo7yIIBo4ZhCIYK6FF6ox0lHq2Hnl167JNjawZoibFpWXhevGMy1Ba5LNs/pcAzf/DvwBogVpOp+QYdzcSE/SU9xTsDhOD5fC09/jryCmQwtmqSBJ2og+jCEce/k1ZxfKIGKJf8v8wBTmiQnulFb/X7DIc+qIks=
localhost.1-wire.fr. 86400 IN A 127.0.0.1
localhost.1-wire.fr. 86400 IN RRSIG A 7 3 86400 20130722215806 20130715134757 54587 1-wire.fr. DuYXMjs1JqMBhBRN4leKeQ35aKYbJY/sFX18Ay/Gsw+mBvZmhYiIpEvF5S+6Y2DdsfW4cACRFHgcH1xA+4x6bZ8qgx9a0chUvPhZEYxE4x+OUPQIxiHTuv1uMggFn3IXzVa6gF2LyzXcTpVllTgv+/ys5CEsGMi9tIW6dkKw1jI=
fui5h4nkfd427prmp83unqg52ah4ecs5.1-wire.fr. 600 IN NSEC3 1 0 100 a6b05497e26b2e5a rbbkes60aq8v8tj8993u9jc7g0nnvmkd A RRSIG
fui5h4nkfd427prmp83unqg52ah4ecs5.1-wire.fr. 600 IN RRSIG NSEC3 7 3 600 20130722142056 20130715134757 54587 1-wire.fr. O02p9ZOPhrzIy+BOpJ1/GlYAVmqvPGoOu4nI7dvuuYMwKGAPjsO0fDKz+6+1Wm5DfXVYseec95IK8YfLpuF3q+jAJZ0OUov+5b3TJAwH+Etv9UxkHVW12uA9hL/1X5iehEH6d+LXZUKtwFnsanLSvlchJf4JQrnxEBmmdmH6R4A=
www.1-wire.fr. 86400 IN CNAME 1-wire.fr.
www.1-wire.fr. 86400 IN RRSIG CNAME 7 3 86400 20130722090344 20130715134757 54587 1-wire.fr. RF00wQjwTUDvIYLqNtqpnLNW24gBbb9FQLmmt5KccbFVcRIop99GFIvjWZOf2bNFVStSgIgbYdMYB1SpfAppYw8jDmOcmjNc1pcWtcyVXMvFrtEgozKqt3sCykqRRWOwiFXXg0KB/QqfBa51u9PJxmJG5XqvqX0DztSRWkZOCPU=
3tok8i9ahpvn7voas6f25dbnlcrkt32m.1-wire.fr. 600 IN NSEC3 1 0 100 a6b05497e26b2e5a 51a6th45ca1hnfa540p77t6d79flpfnj CNAME RRSIG
3tok8i9ahpvn7voas6f25dbnlcrkt32m.1-wire.fr. 600 IN RRSIG NSEC3 7 3 600 20130722082512 20130715134757 54587 1-wire.fr. getervzzrXmyuvYOkeElN+Ztd4nb2xTLHRFrNWfo2bXwQYVx0700xva7X8kxsw2ozC9R731jlqO8YUl9g7z7k12udndO3eZ2XBu7XAoQckuUBuBNR5wqgrcXlt48tfVzJGwcjg2Ak9W+Gj/tLNe/JE8vBW42+4qD8Y7wO4JoWAk=
I get :
# validns -p all -z 1-wire.fr master/1-wire.fr.signed2
master/1-wire.fr.signed2:15: 1-wire.fr. RRSIG(SOA): cannot verify the signature
And I don't really understand what's happening, as tools like http://dnssec-debugger.verisignlabs.com/ don't seem to find any problem.
DANE/TLSA records will appear soon (Type 52, see
http://www.iana.org/assignments/dns-parameters and
http://www.rfc-editor.org/internet-drafts/draft-ietf-dane-protocol-23.txt) so it would be nice to have support for them.
Hi,
I have a zone which contains records with IDN characters. "Example: é ". Validns outputs an error record name is not valid. So it seems validns can not handle idn characters?
Can this be solved?
Thanks
Via Daniel Stirnimann:
$TTL 1d
$INCLUDE Kexample.com.+008+18169.key
$INCLUDE Kexample.com.+008+57699.key
@ IN SOA ns.example.com. hostmaster.example.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns1.example.net.
sub IN NS ns1.example.net.
test.sub IN A 127.0.0.1
The error is that there exists the "test.sub" record but "sub" is
already delegated.
BIND "dnssec-signzone" ignores "test.sub" and does not create
RRSIG/NSEC/NSEC3 records.
When I verify the signed zone (using NSEC) with validns, no error is shown.
When I verify the signed zone (using NSEC3) with validns, the error:
"no corresponding NSEC3 found for test.sub.example.com." is shown which
is correct.
I'm not sure what's the right way of handling this error is. In any
case, I think the error message should be the same whether NSEC or NSEC3
is used. Practically, I could live with a WARNING and not an ERROR
because, as far as BIND dnssec-signzone goes, the additional record of
the delegated zone is not signed, so does not lead to a signing error.
However, I'm not sure if other DNSSEC signing tools handle this the same
way.
Validns throws an error when the number of content fields for a TXT records exceeds 20, a total of 5100 bytes. Did you find a hard limit in one of the major resolvers or did this just sound like a sane upper limit?
RFC8080 has recently come out for DNSSEC algorithms 15 and 16.
Could support for this be added to ValiDNS?
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
This seems relevant (it was the change for algo 13 and 14):
9933f9e#diff-a0852e4180b9be371d862a8d62070cdc
Issue #51 also seems relevant.
When reading a zone file, the number of RR per type should be counted and reported at the end. The output can be used to do further validation, e.g. compare the number of records with a master database or with previous runs.
Example:
record count by type:
A: 1234
NS: 1234
SOA: 1
MX: 1234
AAAA: 1234
SRV: 1
DS: 1234
RRSIG: 1234
DNSKEY: 2
NSEC3: 1234
NSEC3PARAM: 1
Regards,
Patrick
RFC 6844
Trying to validate our zones before signing, found one zone which causes multiple reported errors by validns (version 0.7, also the current github master), but is reported as correct by named-checkzone (and bind 9.9.4), as well as by ldns-verify-zone (apart from one bug in that validator). Also the bind loads and serves that zone correctly.
The issue is mainly about parsing labels containing special characters like UTF-8 and spaces. As far as I can tell these are correctly quoted according to RFC 1035 zone file format. The two "name server domain name is not valid" errors are especially weird.
This is the result of running validns on that file, no command line options:
db-test:13: name server domain name is not valid
db-test:14: a dot within a label is not currently supported
db-test:15: name server domain name is not valid
db-test:18: record name is not valid
db-test:19: cannot assume previous name for it is not known
db-test:20: a dot within a label is not currently supported
db-test:21: cannot assume previous name for it is not known
db-test:22: record name is not valid
db-test:23: cannot assume previous name for it is not known
db-test:28: record name expected
db-test:29: record name expected
db-test:30: record name is not valid
And here is the zone file db-test (I hope the 8-bit bytes will be preserved in the following quotation):
$ORIGIN ijs.si.
$TTL 3600
@ 86400 IN SOA niobe.ijs.si. hostmaster.ijs.si. (
2013110961 28800 3600 2419200 3600 )
NS niobe.ijs.si.
niobe A 193.2.4.24
niobe AAAA 2001:1470:ff80::24
www A 193.2.4.17
www AAAA 2001:1470:ff80::80:1
nabiralnik A 193.2.4.16
nabiralnik AAAA 2001:1470:ff80::80:16
_http._tcp PTR 01\ Institut\ \"Jožef\ Stefan\"._http._tcp
PTR 02\ Koledar\.prireditev._http._tcp
PTR 03\ WLAN\ @\ IJS,\ Eduroam._http._tcp
PTR 04\ Web\ access\ to\ IJS\ mailboxes._http._tcp
01\ Institut\ \"Jožef\ Stefan\"._http._tcp SRV 0 0 80 www
TXT "path=/"
02\ Koledar\.prireditev._http._tcp SRV 0 0 80 www
TXT "path=/ijsw/Koledar_prireditev"
03\ WLAN\ @\ IJS,\ Eduroam._http._tcp SRV 0 0 80 www
TXT "path=/ijsw/Brez%C5%BEi%C4%8Dno_omre%C5%BEje"
04\ Web\ access\ to\ IJS\ mailboxes._http._tcp SRV 0 0 80 nabiralnik
TXT "path=/"
test-lat1 TXT "ma\241ana en M\252nchen"
"ma\241ana" TXT "ma\241ana en M\252nchen"
"la manyana" TXT "ma\241ana en M\252nchen"
la-mañana TXT "ma\241ana en M\252nchen"
It would be nice if the unrecognized directive error gave more information on the directive so it is easier to separate out BIND or other proprietary directives from other errors. For example the $GENERATE option in BIND zone files which can be numerous.
Or maybe this is also something that can be handled with the future lua policy files (having a BIND specific exception file, etc).
Here is a working brew formula.
Odds of getting into brew official are slim/none even though validns is important and really handy.
Closing, it's done.
validns currently fails to verify the zone if there are any fingerprints with algorithm 4 (Ed25519)
When there is a DS-RR for a domain name, there must also be at least 2 NS-RR. This is a requirement of the german registry DENIC.
Regards,
Patrick
Should be fairly easy to implement. They are described in section 3.1 and 3.2 of RFC7344
It seems that if you specify TTL for the first RR of an RRset, the TTL is not propagated to the rest of the RRset, e.g.:
@ 300 MX 0 spg.kirei.se.
MX 5 spg-ipv4.kirei.se.
results in:
"TTL values differ within an RR set"
Even if you're using algorithm 253 (which is private), I don't think that validns should complain about delegation data such as the quality of the DS records (only if they break really bad). Now validns complains if the DS is using algorithms it doesn't recognize. Maybe this should be configurable?
Currently a ietf draft, but expected to be RFC in a few weeks. https://tools.ietf.org/html/draft-ietf-dane-smime-15
Validns 0.8 reports inconsistencies in the NSEC3 chain regarding mixed hash-alogrithms. Like those two NSEC3 RRs:
nt3p0u8gvljva4rhrfrsquk64ehkpfmi.de. 3600 I N NSEC3 2 1 16 0947e8799e2a1326 o0ck6cu1h02gebpq458pkefv1j5qdfm3 NS SOA RRSIG DNSKEY NSEC3PARAM
5pi10b6oo32ackimi5entgjkhtasdtru.de. 3600 IN NSEC3 1 1 16 0947e8799e2a1326 5q1jgrrol77ft0873j0pr9f41r5mtha3 A RRSIG
Unfortunately it does not detect if there is a mismatch of the salt and iterations or the Opt-In / Opt-Out Flag.
Here are some examples for the cases which are not detected:
Opt-In/Opt-Out:
nt3p0u8gvljva4rhrfrsquk64ehkpfmi.de. 3600 IN NSEC3 1 0 16 0947e8799e2a1326 o0ck6cu1h02gebpq458pkefv1j5qdfm3 NS SOA RRSIG DNSKEY NSEC3PARAM
ljpe46seqcufhqtbho12nd877sgvohlt.de. 3600 IN NSEC3 1 1 16 0947e8799e2a1326 lm8cmbau3njoq7mhakq35btbohposf1q A RRSIG
Iterations:
nt3p0u8gvljva4rhrfrsquk64ehkpfmi.de. 3600 IN NSEC3 1 1 17 0947e8799e2a1326 o0ck6cu1h02gebpq458pkefv1j5qdfm3 NS SOA RRSIG DNSKEY NSEC3PARAM
db4dqnt03hg68utinuksrifbirrtm969.de. 3600 IN NSEC3 1 1 16 0947e8799e2a1326 dbjimap2ouup2nfmh1digdu2fbvkrof5 NS DS RRSIG
Salt:
nt3p0u8gvljva4rhrfrsquk64ehkpfmi.de. 3600 IN NSEC3 1 1 16 DEADBEEF o0ck6cu1h02gebpq458pkefv1j5qdfm3 NS SOA RRSIG DNSKEY NSEC3PARAM
vq0lr2sjgbblgehekbf6n6bv52fl3mno.de. 3600 IN NSEC3 1 1 16 0947e8799e2a1326 vvg7t4t2mqchdinbkl7b4ms8ii9l6l35 A RRSIG
The easiest way to check this is to check if each NSEC3-Record matches any NSEC3PARAM.
This implies that all NSEC3 records matching a specific NSEC3PARAM have consistent salt and iterations.
The branch supporting them appears to be simply missing at
Line 151 in 60c842b
The german registry DENIC knows two kind of domains:
A domain with NS-RR must not have A-, AAAA- or MX-RR (except glue records).
I believe this issue could be pretty DENIC specific, so I'm not sure if this should be officially implement in validns.
Regards,
Patrick
There are certain constraints on the format of the tag values, which validns currently ignores.
When using the Best Current Practice RFC 2317 for class-less delegation, the suggested syntax is to use a "/" (slash). For example:
0/25 NS ns.A.domain.
0/25 NS some.other.name.server.
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
2 CNAME 2.0/25.2.0.192.in-addr.arpa.
validns breaks when validating the signed zone. Some of the reported errors:
1.0/25.2.0.192.in-addr.arpa. 86400 IN CNAME 1.0/25.2.0.192.in-addr.arpa.
-> cname is not valid
0.2.0.192.in-addr.arpa. 1800 IN NSEC 0/25.2.0.192.in-addr.arpa. CNAME RRSIG NSEC
-> next domain is not valid
-> type list expected
0/25.2.0.192.in-addr.arpa. 86400 IN NS ns.A.domain.
-> record name is not valid
Seems like validns does not accept the "/"
RFC 6672 will be published in a few days, replacing RFC 2672, and it insists that only one DNAME is allowed per name. Example of a wrong zone:
sub IN DNAME example.org.
sub IN DNAME example.net.
BIND 9.9.1 refuses to load zones with this error:
23-May-2012 22:39:35.847 dns_master_load: foobar.example:20: sub.foobar.example: multiple RRs of singleton type
23-May-2012 22:39:35.847 zone foobar.example/IN: loading from master file foobar.example failed: multiple RRs of singleton type
23-May-2012 22:39:35.847 zone foobar.example/IN: not loaded due to errors.
But validns (git HEAD of today) accepts:
% ./validns -z foobar.example /tmp/bind/foobar.example
%
A policy check which could recover the private key would be interesting.
BIND 9.9.6 and newer support CAA records.
It would be cool, if validns supports this RR (https://tools.ietf.org/html/rfc6844).
dnssec-signzone from BIND 9.10.3-P4 or BIND 9.9.8-P4 and earlier have a bug which does not remove unnecessary rrsigs from zone. It is fixed for upcoming releases:
- [bug] dnssec-signzone was not removing unnecessary rrsigs
from the zone's apex. [RT #41483]
Specifically, it was fixed on the 28th Jan 2016:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=832ab79d1f8bc4edf638780b306888da30ac3a1e
validns will detect these signatures. e.g.:
validns 8.example.com.signed
8.example.com.signed:47: 8.example.com. RRSIG exists for non-existing type A
Note that both ldns-verify-zone or dnssec-verify ignore these rrsigs:
ldns-verify-zone 8.example.com.signed
Checking: 8.example.com.
Checking: www.8.example.com.
Zone is verified and completednssec-verify -x -o 8.example.com. 8.example.com.signed
Loading zone '8.example.com.' from file '8.example.com.signed'
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 present, 0 revoked
Instead of permanently ignore unnecessary rrsigs I think a policy check for this explicit case is appropriate.
The .se zone has RP records in the zone, with RRSIGS over it. This gives you the following errors:
se.new:6187555: invalid or unsupported rdtype rp
se.new:6187556: class or type expected
se.new:6187557: class or type is not valid
on this data:
a.ns.se. 172800 IN RRSIG RP 5 3 172800 20111112001420 (
20111030010504 33951 se.
BPJxbZ2muS/TtcwJktVNMxXPSqLbzKC7SryPfhIfLZhuY
ihCLQfhnfyRmYbCj1cXqKpX7LH2Hnwp1hkuI19nIS8EWl
oxPt5FrlkHgjzO9I4r/44lKcwzn9dh0OB/I617n8jHDEc
x4KtYrsitbhSH9AFiMAO26TP+aaoKJ6kDWN8= )
dito
Hi,
the implementation of a possibility ( policy ) to check for an existing KSK record and the appropriate RRSIG in the zone. This offers the possibility to verify the validation of the signatures against the whole chain.
This would be a nice feature..
Thanks
greetz
Christian
Should be simple to add I guess.
Hi,
the implementation of a possibility ( policy ) to check for an existing KSK record and the appropriate RRSIG in the zone. This offers the possibility to verify the validation of the signatures against the whole chain.
This would be a nice feature..
Thanks
greetz
Christian
Daniel Stirnimann writes:
I have a question regarding the DNSSEC check "NSEC3 without a
corresponding record (or empty non-terminal)".
My sample zone example.com looks as follow:
$TTL 1d
$INCLUDE Kexample.com.+008+18169.key
$INCLUDE Kexample.com.+008+57699.key
@ IN SOA ns.example.com. hostmaster.example.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns1.example.net.
1.1.1.1.1.1.1.1.1.1.33 IN NS ns1.example.net.
I sign the zone with the following command:
dnssec-signzone -t -3 94CD -H 1 example.com
validns (v0.4) gives me ten validation errors for the above mentioned
"empty non-terminal" check.
Why is this considered an error? Empty non-terminals have NSEC3 records.
So where is the problem?
funny how I got to be the one to have http://dlv.isc.org/ support the case when the zone had a dname record, and now, well, I try validns, and kaboom, it does not support dname either :-)
It's kinda like a CNAME, but an automatic one, in this : only the first and the last line really exit, the second one is generated by bind so that an old resolver would understand :
# dig +dnssec +noall +answer a webmail.absolight.info @127.0.0.1
absolight.info. 86400 IN DNAME absolight.fr.
absolight.info. 86400 IN RRSIG DNAME 7 2 86400 20111121053253 20111114080145 33560 absolight.info. p0wI0qeCigft8q/OAoADieU+FVYoRigembraellIOEFJX+bOLCcPTnTg z7ihA02Kh78ascKum8dA5eSfjN8hV/TNwv3Qi3kDUoJdzeBnxE16vyHZ u3k6sCk241w27RvoUGmuoBcwg1U+UresJrUS+Xfnur8+rUj/OLrmDn3f btI=
webmail.absolight.info. 86400 IN CNAME webmail.absolight.fr.
webmail.absolight.fr. 86400 IN A 193.30.224.134
webmail.absolight.fr. 86400 IN RRSIG A 7 3 86400 20111122131429 20111115042533 60623 absolight.fr. cKmZd878iyhHanl4cg6AAzJAdfuQqI5b6DCU1VpYLIWbkGXqo3EE99Ow Ht8RILd5fe991xCff5jK1DrENiC/TdoTlnLODRcfzpM8lT/EpyiqFQLf nOqkRLzA01CDwpnSctKa+7paEGbFIqLzNhRKggcnBaOJXMa9E5wlyhGd cxc=
The codes for the four ILNP records (NID, L64, L32 and LP) have been added to the IANA registry http://www.iana.org/assignments/dns-parameters. The future RFC is in the RFC Editor Queue http://www.rfc-editor.org/internet-drafts/draft-irtf-rrg-ilnp-dns-06.txt
It would be cool to have validns support for them.
I've just written a FreeBSD port skeleton for validns 0.4.
It builds and deletes cleanly on 9.0|8.2|7.4-RELEASE and 10-CURRENT.
https://gist.github.com/2488296
Feel free to tune MAINTAINER and Whom line in the Makefile and submit a PR
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.