Re: SSHFP observation
> 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 >>> 4255 and errata in your answer. >> >> Mathematics. I’ll presume I can use all of the RFC some of which state >> minimum sizes for cryptographic hashes. Developers are expected to use >> all their knowledge. > > Developers are supposed to follow the RFC. For "future proofing", I > can't see adding a constraint that isn't in the RFC. RFC’s don’t always specify what is needed. They are written by humans and sometimes there is no answer yet. >> There is no minimum size on that field though clearly 8 bits >> is insane. Is a empty field allowed? > > I'm not going to question anyone's sanity. We do DNS for a living. How > sane is that? Hm? Yeah, thought so. It could indicate that SSH is not supported at on this host along with 0 0 in the first two field. That hasn’t been defined yet to the best of my knowledge but it could be. The future is hard to predict, but we still need to allow for it. c.f. example.com. MX 0 . >>> My reading: The RFC doesn't specify what a fingerprint is other than "an >>> opaque octet string [..] which is placed as-is in the RDATA fingerprint >>> field.” >> >> It also specifies that 1 is SHA-1 and there is a followup RFC that specifies >> 2 is SHA256. In this case the record is clearly wrong as it is too short >> to be SHA1. > > That means that we have a BUNCH of "still to be allocated" algorithms. > I'm not smart enough to say exactly what they are going to need to > encode in that "fingerprint" field other than something encoded in hex. > One byte? More? Sure! > > The RFC doesn't specify a minimum, named doesn't enforce a two-byte > minimum - what are we arguing about again? > > Oh yeah... dig doesn't like one byte. > > So... WHY are we arguing about this? Because we like to have friendly arguments at times. We could leave this as is or s/4/3/ and be done (or should that be s/4/2/ :-)). We could also teach BIND about what the value 1 and 2 mean and enforce the rdata length for those values. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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 I can use all of the RFC some of which state > minimum sizes for cryptographic hashes. Developers are expected to use > all their knowledge. Developers are supposed to follow the RFC. For "future proofing", I can't see adding a constraint that isn't in the RFC. > There is no minimum size on that field though clearly 8 bits > is insane. Is a empty field allowed? I'm not going to question anyone's sanity. We do DNS for a living. How sane is that? Hm? Yeah, thought so. >> My reading: The RFC doesn't specify what a fingerprint is other than "an >> opaque octet string [..] which is placed as-is in the RDATA fingerprint >> field.” > > It also specifies that 1 is SHA-1 and there is a followup RFC that specifies > 2 is SHA256. In this case the record is clearly wrong as it is too short > to be SHA1. That means that we have a BUNCH of "still to be allocated" algorithms. I'm not smart enough to say exactly what they are going to need to encode in that "fingerprint" field other than something encoded in hex. One byte? More? Sure! The RFC doesn't specify a minimum, named doesn't enforce a two-byte minimum - what are we arguing about again? Oh yeah... dig doesn't like one byte. So... WHY are we arguing about this? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
> 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. 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 decision from my reading. >>> >>> There is nothing in the RFC about validating the correctness of the data: >> >> I'm not following your logic. The RFC says a field is the fingerprint >> and the user supplied data can't possibly be a fingerprint. It seems >> to me there's a requirement to reject the user supplied data since it >> can't possibly be a fingerprint. > > 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 I can use all of the RFC some of which state minimum sizes for cryptographic hashes. Developers are expected to use all their knowledge. > My reading: The RFC doesn't specify what a fingerprint is other than "an > opaque octet string [..] which is placed as-is in the RDATA fingerprint > field.” It also specifies that 1 is SHA-1 and there is a followup RFC that specifies 2 is SHA256. In this case the record is clearly wrong as it is too short to be SHA1. > To be fair, the RFC does point off to the SSH TLS documentation. If we > wander off into that realm, we may want to start considering validating > that the hex data is a crypto. valid fingerprint, etc. etc. > > That's the way I read it. > > In any case, either: > 1) named should not load the zone >it's just as bad as an A record with 5 octets >(this is a bug in named) > or > 2) dig should provide the correct decoding of the >data provided to it by named. >(this is a bug in dig) > > I don't care which, but I'm leaning towards #2. > > And no, an empty field is NOT allowed due to the same logic as "My > reading" above (answering Mark's question that came in while I was > researching and typing this) > > Be well, all. > > AlanC > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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 it's junk, the RFC doesn't give the DNS software the >> ability to make that decision from my reading. >> >> There is nothing in the RFC about validating the correctness of the data: > > I'm not following your logic. The RFC says a field is the fingerprint > and the user supplied data can't possibly be a fingerprint. It seems > to me there's a requirement to reject the user supplied data since it > can't possibly be a fingerprint. 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. My reading: The RFC doesn't specify what a fingerprint is other than "an opaque octet string [..] which is placed as-is in the RDATA fingerprint field." To be fair, the RFC does point off to the SSH TLS documentation. If we wander off into that realm, we may want to start considering validating that the hex data is a crypto. valid fingerprint, etc. etc. That's the way I read it. In any case, either: 1) named should not load the zone it's just as bad as an A record with 5 octets (this is a bug in named) or 2) dig should provide the correct decoding of the data provided to it by named. (this is a bug in dig) I don't care which, but I'm leaning towards #2. And no, an empty field is NOT allowed due to the same logic as "My reading" above (answering Mark's question that came in while I was researching and typing this) Be well, all. AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
> 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. >> >> While I agree that it's junk, the RFC doesn't give the DNS software the >> ability to make that decision from my reading. >> >> There is nothing in the RFC about validating the correctness of the data: > > I'm not following your logic. The RFC says a field is the fingerprint > and the user supplied data can't possibly be a fingerprint. It seems > to me there's a requirement to reject the user supplied data since it > can't possibly be a fingerprint. There is no minimum size on that field though clearly 8 bits is insane. Is a empty field allowed? For digest types 1 and 2 we know what the field size is. For the rest it is a unknown. SSH needs to check the rdata size. Name servers not so much. They can just push the bits. Some responsibility needs to fall on the operator. Named allowed you to load garbage in that field. Meh. > Regards, > Lee > >> >> -- >> The RDATA of the presentation format of the SSHFP resource record >> consists of two numbers (algorithm and fingerprint type) followed by >> the fingerprint itself, presented in hex, e.g.: >> >> host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 >> -- >> >> AlanC -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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 software the > ability to make that decision from my reading. > > There is nothing in the RFC about validating the correctness of the data: I'm not following your logic. The RFC says a field is the fingerprint and the user supplied data can't possibly be a fingerprint. It seems to me there's a requirement to reject the user supplied data since it can't possibly be a fingerprint. Regards, Lee > > -- >The RDATA of the presentation format of the SSHFP resource record >consists of two numbers (algorithm and fingerprint type) followed by >the fingerprint itself, presented in hex, e.g.: > >host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 > -- > > AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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 decision from my reading. There is nothing in the RFC about validating the correctness of the data: -- The RDATA of the presentation format of the SSHFP resource record consists of two numbers (algorithm and fingerprint type) followed by the fingerprint itself, presented in hex, e.g.: host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 -- AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
> 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/issues/852 > > has been re-opened. I still think it's a junk fingerprint, but it does > appear to me to be legal per-RFC. 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. > AlanC > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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, but it does appear to me to be legal per-RFC. AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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) should not complain about malformed > responses. 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. AlanC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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 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) should not complain about malformed responses. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I feel like I'm diagonally parked in a parallel universe. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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 bug. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SSHFP observation
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 . Regards, Ramesh On Thu, 31 Jan 2019, 7:14 pm rams 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 wrong then > bind should validate and should not start. Is it expected behavior? Kindly > confirm. > > Bind responses > [qa][root@regression-bind-useast1a01-01 zones]# dig @localhost > test2.ramesh-sshfp.com. sshfp > ;; Warning: Message parser reports malformed message packet. > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> @localhost > test2.ramesh-sshfp.com. sshfp > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49768 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > ;; WARNING: Messages has 55 extra bytes at end > > ;; QUESTION SECTION: > ;test2.ramesh-sshfp.com.IN SSHFP > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Thu Jan 31 13:29:18 2019 > ;; MSG SIZE rcvd: 107 > > [qa][root@regression-bind-useast1a01-01 zones]# dig @localhost > test1.ramesh-sshfp.com. sshfp > ;; Warning: Message parser reports malformed message packet. > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> @localhost > test1.ramesh-sshfp.com. sshfp > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23302 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > ;; WARNING: Messages has 55 extra bytes at end > > ;; QUESTION SECTION: > ;test1.ramesh-sshfp.com.IN SSHFP > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Thu Jan 31 13:29:23 2019 > ;; MSG SIZE rcvd: 107 > > [qa][root@regression-bind-useast1a01-01 zones]# > > Regards, > Ramesh > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: SSHFP observation
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: svlg-gateway IN SSHFP 1 2 5d0d289579841c3f158d5d6e3f9358d6ffa72f4e8a4625480e1502471121 svlg-gateway IN SSHFP 2 2 dbe0bb71cdcc3179a63a39e924c54b7884058318219f76ddc502f4d0b56f9041 svlg-gateway IN SSHFP 3 2 6fae021dd9c8d84448a0a15623751a1e35e56f5aa2d86193097b6d1008c14c42 svlg-gateway IN SSHFP 4 2 da6681ec8d06d7da14121bf717849c4044a1ccdac9a8a6398ceb1de1cafd5d3f test1 SSHFP 1 1 aa test2 SSHFP 1 1 00 root@svlg-gateway:/etc/namedb/zone# dig test1.boat sshfp ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.13.5 <<>> test1.boat sshfp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41738 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: Message has 42 extra bytes at end ;; QUESTION SECTION: ;test1.boat.IN SSHFP ;; Query time: 1 msec ;; SERVER: 44.127.8.1#53(44.127.8.1) ;; WHEN: Thu Jan 31 16:25:27 UTC 2019 ;; MSG SIZE rcvd: 82 root@svlg-gateway:/etc/namedb/zone# dig svlg-gateway.boat sshfp ; <<>> DiG 9.13.5 <<>> svlg-gateway.boat sshfp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36644 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: fc5043961ba7f3de20111bd95c5321822d0203038e0ff9df (good) ;; QUESTION SECTION: ;svlg-gateway.boat. IN SSHFP ;; ANSWER SECTION: svlg-gateway.boat. 300 IN SSHFP 3 2 6FAE021DD9C8D84448A0A15623751A1E35E56F5AA2D86193097B6D10 08C14C42 svlg-gateway.boat. 300 IN SSHFP 2 2 DBE0BB71CDCC3179A63A39E924C54B7884058318219F76DDC502F4D0 B56F9041 svlg-gateway.boat. 300 IN SSHFP 1 2 5D0D289579841C3F158D5D6E3F9358D6FFA72F4E8A4625480E15 02471121 svlg-gateway.boat. 300 IN SSHFP 4 2 DA6681EC8D06D7DA14121BF717849C4044A1CCDAC9A8A6398CEB1DE1 CAFD5D3F ;; Query time: 1 msec ;; SERVER: 44.127.8.1#53(44.127.8.1) ;; WHEN: Thu Jan 31 16:25:38 UTC 2019 ;; MSG SIZE rcvd: 258 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: SSHFP observation
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.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 > > > wrong > > > then bind should validate and should not start. Is it expected > > > behavior? Kindly confirm. > > > > Bind will restart cleanly unless you muck up something in the > > config file(s). In this case you have something wrong in a zone > > file, and we can't see what it is because the domain you specified > > is invalid. So, until you show us some data my best guess is that > > you have a formatting error in a zone file(s). > > > > Help us help you by specifying the actual domain. > > The original poster is right. Something is broken in SSHFP > processing. He's configured a zone with the above records, and > querying against that zone is causing dig to print that the reply is > malformed. > BIND should never return a malformed message, so there is a bug > somewhere. The malformed messages are from dig (v9.8.2rc1-RedHat-9.8.2- 0.30.rc1.el6_6.3) Warning: Message parser reports malformed message packet. WARNING: Messages has 55 extra bytes at end We know nothing yet about the BIND setup/version/zone/etc/ For all we know the zone is fat fingered. -Jim P. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: SSHFP observation
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 1 1 00 > > > > Successfully started bind but when queried for domain test1 and test2 > > , returning malformed error and no answer. If fingerprint value wrong > > then bind should validate and should not start. Is it expected > > behavior? Kindly confirm. > > Bind will restart cleanly unless you muck up something in the config > file(s). In this case you have something wrong in a zone file, and we > can't see what it is because the domain you specified is invalid. So, > until you show us some data my best guess is that you have a formatting > error in a zone file(s). > > Help us help you by specifying the actual domain. The original poster is right. Something is broken in SSHFP processing. He's configured a zone with the above records, and querying against that zone is causing dig to print that the reply is malformed. BIND should never return a malformed message, so there is a bug somewhere. Mukund ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: SSHFP observation
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 > , returning malformed error and no answer. If fingerprint value wrong > then bind should validate and should not start. Is it expected > behavior? Kindly confirm. Bind will restart cleanly unless you muck up something in the config file(s). In this case you have something wrong in a zone file, and we can't see what it is because the domain you specified is invalid. So, until you show us some data my best guess is that you have a formatting error in a zone file(s). Help us help you by specifying the actual domain. -Jim P. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Fwd: SSHFP observation
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 wrong then bind should validate and should not start. Is it expected behavior? Kindly confirm. Bind responses [qa][root@regression-bind-useast1a01-01 zones]# dig @localhost test2.ramesh-sshfp.com. sshfp ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> @localhost test2.ramesh-sshfp.com. sshfp ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49768 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: Messages has 55 extra bytes at end ;; QUESTION SECTION: ;test2.ramesh-sshfp.com.IN SSHFP ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jan 31 13:29:18 2019 ;; MSG SIZE rcvd: 107 [qa][root@regression-bind-useast1a01-01 zones]# dig @localhost test1.ramesh-sshfp.com. sshfp ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> @localhost test1.ramesh-sshfp.com. sshfp ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23302 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: Messages has 55 extra bytes at end ;; QUESTION SECTION: ;test1.ramesh-sshfp.com.IN SSHFP ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jan 31 13:29:23 2019 ;; MSG SIZE rcvd: 107 [qa][root@regression-bind-useast1a01-01 zones]# Regards, Ramesh ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dnssec setting resolving weird
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.234#44542 (flingo.tv): query: flingo.tv IN A + (66.50.101.234) 31-Jan-2019 09:15:23.346 client @0x7f786c0e6f10 66.50.101.234#44542 (flingo.tv): query (cache) 'flingo.tv/A/IN' approved 31-Jan-2019 09:15:23.346 fetch: flingo.tv/A ... 31-Jan-2019 09:15:25.055 no valid DS resolving 'flingo.tv/A/IN': 205.251.195.243#53 ... 31-Jan-2019 09:15:28.346 client @0x7f78401002e0 66.50.101.234#44542 (flingo.tv): query: flingo.tv IN A + (66.50.101.234) 31-Jan-2019 09:15:28.346 client @0x7f78401002e0 66.50.101.234#44542 (flingo.tv): query (cache) 'flingo.tv/A/IN' approved 31-Jan-2019 09:15:28.346 fetch: flingo.tv/A 31-Jan-2019 09:15:28.346 client @0x7f78401002e0 66.50.101.234#44542 (flingo.tv): request failed: duplicate query ... 31-Jan-2019 09:15:33.346 client @0x7f785c0dff90 66.50.101.234#44542 (flingo.tv): query: flingo.tv IN A + (66.50.101.234) 31-Jan-2019 09:15:33.346 client @0x7f785c0dff90 66.50.101.234#44542 (flingo.tv): query (cache) 'flingo.tv/A/IN' approved 31-Jan-2019 09:15:33.346 fetch: flingo.tv/A 31-Jan-2019 09:15:33.346 client @0x7f785c0dff90 66.50.101.234#44542 (flingo.tv): request failed: duplicate query ... 31-Jan-2019 09:15:35.097 no valid DS resolving 'flingo.tv/A/IN': 205.251.195.243#53 -- Ismael -Original Message- From: @lbutlr mailto:%22@lbutlr%22%20%3ckrem...@kreme.com%3e>> To: bind-users@lists.isc.org mailto:%22bind-us...@lists.isc.org%22%20%3cbind-us...@lists.isc.org%3e>> Subject: Re: Dnssec setting resolving weird Date: Wed, 30 Jan 2019 14:40:47 -0700 On 30 Jan 2019, at 14:21, Ismael Suarez mailto:ismael_sua...@coqui.com>> wrote: This is puzzling me big time. Maybe I’m missing something obvious. Don’t know. There must be something in the logs? This email was scanned by Bitdefender ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC setup hint
@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 files are (mostly) in "etc". I'm not sure why you say the .key files "need" to go anywhere. As I understand it, `named` doesn't use the .key files, but various other tools expect them to be next to the .private files. > Also, though this is more obvious, make sure you set the owner to bind > for akk the key files, as when you create them they will almost > certainly be owned by root. Yes, I keep stubbing my toe on this problem. My `key-directory` is set-gid `named` so I just need to `chgrp +r` the .private files after doing anything with them. I'm not sure what is the right way to fix this, since it's hard for a program to know what the sysadmin's security model for a group is. Maybe setgid on the directory is enough of a hint? dunno. Tony. -- f.anthony.n.finchhttp://dotat.at/ a fair, free and open society ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
