> On 1 Feb 2019, at 11:34 am, Alan Clegg wrote:
>
> On 1/31/19 7:19 PM, Mark Andrews wrote:
>
>>> Question: How does named (actually 'dig') know that any given data (in
>>> this case "AA") can't be a fingerprint?
>>> Difficulty: You are only allowed to use the information provided in RFC
>>> 4
On 1/31/19 7:19 PM, Mark Andrews wrote:
>> Question: How does named (actually 'dig') know that any given data (in
>> this case "AA") can't be a fingerprint?
>> Difficulty: You are only allowed to use the information provided in RFC
>> 4255 and errata in your answer.
>
> Mathematics. I’ll presume
> On 1 Feb 2019, at 11:10 am, Alan Clegg wrote:
>
> On 1/31/19 6:44 PM, Lee wrote:
>> On 1/31/19, Alan Clegg wrote:
>>> On 1/31/19 4:57 PM, Mark Andrews wrote:
>>>
Given type 1 is a SHA-1 fingerprint it isn’t legal. Named just
hasn’t added type to length to the parsing code.
>
On 1/31/19 6:44 PM, Lee wrote:
> On 1/31/19, Alan Clegg wrote:
>> On 1/31/19 4:57 PM, Mark Andrews wrote:
>>
>>> Given type 1 is a SHA-1 fingerprint it isn’t legal. Named just
>>> hasn’t added type to length to the parsing code.
>>>
>>> No real SSHFP will be 1 octet long.
>>
>> While I agree that
> On 1 Feb 2019, at 10:44 am, Lee wrote:
>
> On 1/31/19, Alan Clegg wrote:
>> On 1/31/19 4:57 PM, Mark Andrews wrote:
>>
>>> Given type 1 is a SHA-1 fingerprint it isn’t legal. Named just
>>> hasn’t added type to length to the parsing code.
>>>
>>> No real SSHFP will be 1 octet long.
>>
>>
On 1/31/19, Alan Clegg wrote:
> On 1/31/19 4:57 PM, Mark Andrews wrote:
>
>> Given type 1 is a SHA-1 fingerprint it isn’t legal. Named just
>> hasn’t added type to length to the parsing code.
>>
>> No real SSHFP will be 1 octet long.
>
> While I agree that it's junk, the RFC doesn't give the DNS
On 1/31/19 4:57 PM, Mark Andrews wrote:
> Given type 1 is a SHA-1 fingerprint it isn’t legal. Named just
> hasn’t added type to length to the parsing code.
>
> No real SSHFP will be 1 octet long.
While I agree that it's junk, the RFC doesn't give the DNS software the
ability to make that decisi
> On 1 Feb 2019, at 7:34 am, Alan Clegg wrote:
>
> On 1/31/19 2:16 PM, Alan Clegg wrote:
>
>> Ok, fair point. I'll bring it up with the BIND team.
>>
>> If I don't return in 2 weeks, send in a search party.
>
> After a bit of discussion:
>
> https://gitlab.isc.org/isc-projects/bind9/issu
On 1/31/19 2:16 PM, Alan Clegg wrote:
> Ok, fair point. I'll bring it up with the BIND team.
>
> If I don't return in 2 weeks, send in a search party.
After a bit of discussion:
https://gitlab.isc.org/isc-projects/bind9/issues/852
has been re-opened. I still think it's a junk fingerprint,
On 1/31/19 1:12 PM, Matus UHLAR - fantomas wrote:
> On 31.01.19 12:33, Alan Clegg wrote:
>> These are not valid SSH Fingerprints.
>>
>> Garbage in, garbage out.
>>
>> I see no bug.
>
> well, either BIND should reject those records as invalid and not to send
> them, or dig (from bind package) shou
On 1/31/19 12:30 PM, rams wrote:
Thank you Mukund,Jim and Alan to look my issue.
We are seeing the issue only when sshfp fingerprint value less than 4
characters.
It is working fine value with >=4 characters.
On 31.01.19 12:33, Alan Clegg wrote:
These are not valid SSH Fingerprints.
Garbage
On 1/31/19 12:30 PM, rams wrote:
> Thank you Mukund,Jim and Alan to look my issue.
>
> We are seeing the issue only when sshfp fingerprint value less than 4
> characters.
>
> It is working fine value with >=4 characters.
These are not valid SSH Fingerprints.
Garbage in, garbage out.
I see no b
Thank you Mukund,Jim and Alan to look my issue.
We are seeing the issue only when sshfp fingerprint value less than 4
characters.
It is working fine value with >=4 characters.
Ex: test3.ramesh-sshfp.com SSHFP 1 1 WORKING FINE
I am guessing there is bug in bind and posted in bugs list
13 matches
Mail list logo
