@lbutlr wrote:
>
> key-directory in named.conf refers to the location for the .private key
> files, the .key files need to go with the domain conf files.
In my setup, all the key files (.private and .key) are in the
`key-directory`, all the zone files are in a "zone" directory,
and configuration
Logs say (with "dnssec-validation auto;" in the conf):
31-Jan-2019 09:15:23.346 client @0x7f786c0e6f10 66.50.101.234#44542: request is
not signed
31-Jan-2019 09:15:23.346 client @0x7f786c0e6f10 66.50.101.234#44542: recursion
available
31-Jan-2019 09:15:23.346 client @0x7f786c0e6f10 66.50.101.23
Hi,
I have setup sshfp records as follows in bind zone file:
test1.ramesh-sshfp.com. 86400 IN SSHFP 1 1 aa
test2.ramesh-sshfp.com. 86400 IN SSHFP 1 1 00
Successfully started bind but when queried for domain test1 and test2 ,
returning malformed error and no answer. If fingerprint value wron
On Thu, 2019-01-31 at 19:14 +0530, rams wrote:
> Hi,
> I have setup sshfp records as follows in bind zone file:
>
> test1.ramesh-sshfp.com. 86400 IN SSHFP 1 1 aa
> test2.ramesh-sshfp.com. 86400 IN SSHFP 1 1 00
>
> Successfully started bind but when queried for domain test1 and test2
> , ret
On Thu, Jan 31, 2019 at 10:30:30AM -0500, Jim Popovitch via bind-users wrote:
> On Thu, 2019-01-31 at 19:14 +0530, rams wrote:
> > Hi,
> > I have setup sshfp records as follows in bind zone file:
> >
> > test1.ramesh-sshfp.com. 86400 IN SSHFP 1 1 aa
> > test2.ramesh-sshfp.com. 86400 IN SSHFP
On Thu, 2019-01-31 at 21:12 +0530, Mukund Sivaraman wrote:
> On Thu, Jan 31, 2019 at 10:30:30AM -0500, Jim Popovitch via bind-
> users wrote:
> > On Thu, 2019-01-31 at 19:14 +0530, rams wrote:
> > > Hi,
> > > I have setup sshfp records as follows in bind zone file:
> > >
> > > test1.ramesh-sshfp.c
On 1/31/19 10:56 AM, Jim Popovitch via bind-users wrote:
> est1.ramesh-sshfp.com. 86400 IN SSHFP 1 1 aa
> test2.ramesh-sshfp.com. 86400 IN SSHFP 1 1 00
When I use these exact lines (with the "aa" and "00"), I get just what
he did.
When I use lines with correct SSHFP values, they work fine:
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
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
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 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 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 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 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/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 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 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 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 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: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
20 matches
Mail list logo
