search

dnsimple / dns_erlang

Erlang DNS library.
Apache License 2.0
95 stars 25 forks source link

SSHFP output does not match record data #2

Closed aeden closed 10 years ago

aeden commented 10 years ago

Given the fingerprint 8544BD5B4902151F80391563A6511FD864489763, the output when queried with dig is 38353434424435423439303231353146383033393135363341363531 314644383634343839373633

Any thoughts on what might be happening here?

aeden commented 10 years ago

The rdata looks like this:

{dns_rrdata_sshfp,1,1,<<"8544BD5B4902151F80391563A6511FD864489763">>}
andrewtj commented 10 years ago

The fingerprint goes on the wire as is so if you provide it in it's raw form (<<133,68,189,91,73,2,21,31,128,57,21,99,166,81,31,216,100,72,151,99>>) you should get back the expected hex.

The documentation could be improved here but maybe the representation should be changed as well. What do you think?

aeden commented 10 years ago

If I store the fingerprint in its bitstring format at reast, what is the proper way to covert it to a raw binary form?

andrewtj commented 10 years ago

For my own use I'd vendor mochihex and adapt to_bin/1 to accept a binary (and handle bad input if need be). erlang:list_to_integer/2 in a comprehension or similar is also an option, eg: << <<(erlang:list_to_integer([C],16)):4>> || <<C>> <= HexBin >>.

aeden commented 10 years ago

Turns out you have a hex_to_bin function in your library, so I've just cargo-culted that for now. :-)

FWIW, I think I may come back and revisit this in the future with a PR. The representation at rest should probably be a hex string as defined in http://tools.ietf.org/html/rfc4255#section-3.2 and thus the encoder should probably handle the conversion rather than pass it as is.

andrewtj commented 10 years ago

Turns out you have a hex_to_bin function in your library, so I've just cargo-culted that for now. :-)

hah, I'm getting out of touch with my own code.

FWIW, I think I may come back and revisit this in the future with a PR. The representation at rest should probably be a hex string as defined in http://tools.ietf.org/html/rfc4255#section-3.2 and thus the encoder should probably handle the conversion rather than pass it as is.

I think the representation is an issue largely because there is no converters to and from master file format. Maybe adding the following would be the way to go: